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Abstract 

Over the past thirty years, there has been signihcant progress 
in developing general-purpose, language-based approaches 
to incremental computation, which aims to efficiently up¬ 
date the result of a computation when an input is changed. 
A key design challenge in such approaches is how to pro¬ 
vide efficient incremental support for a broad range of pro¬ 
grams. In this paper, we argue that first-class names are 
a critical linguistic feature for efficient incremental com¬ 
putation. Names identify computations to be reused across 
differing runs of a program, and making them hrst class 
gives programmers a high level of control over reuse. We 
demonstrate the benefits of names by presenting NOMI¬ 
NAL Adapton, an ML-like language for incremental com¬ 
putation with names. We describe how to use NOMINAL 
Adapton to efficiently incrementalize several standard pro¬ 
gramming patterns—including maps, folds, and unfolds— 
and show how to build efficient, incremental probabilistic 
trees and tries. Since NOMINAL Adapton’s implementa¬ 
tion is subtle, we formalize it as a core calculus and prove 
it is from-scratch consistent, meaning it always produces 
the same answer as simply re-running the computation. Fi¬ 
nally, we demonstrate that NOMINAL Adapton can pro¬ 
vide large speedups over both from-scratch computation and 
Adapton, a previous state-of-the-art incremental computa¬ 
tion system. 

Categories and Subject Descriptors D.3.1 [Programming 
Languages]: Formal Definitions and Theory; D.3.3 [Pro¬ 
gramming Languages]: Language Constructs and Features; 
F.3.2 [Logics and Meanings of Programs]: Semantics of Pro¬ 
gramming Languages 
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1. Introduction 

Memoization is a widely used technique to speed up running 
time by caching and reusing prior results ( |Michie|[l968| l. 
The idea is simple—the hrst time we call a pure function 
f on immutable inputs x, we store the result r in a memo ta¬ 
ble mapping x to r. Then on subsequent calls f(y), we can 
return r immediately if x and p match. Incremental com¬ 
putation (IC) ( |Pugh| |T988l l takes this idea a step further, 
aiming to reuse prior computations even if there is a small 
change in the input. Recent forms of IC as exemplihed by 
self-adjusting computation (SAC) ( Acar| |2005|l and Adap¬ 
ton ( Hammer et al.|20l4) l support mutable inputs, meaning 
that two calls to f (ic) might produce different results because 
values reachable from the same arguments x have been mu¬ 
tated. As such, before reusing a memoized result r, any in¬ 
consistencies are repaired via a process called change prop¬ 
agation. 

An important goal of an IC system is to minimize the 
work performed in support of change propagation, and thus 
improve overall performance. Matching—the task of deter¬ 
mining whether a call’s arguments are “the same” as those 
of a memoized call—turns out to play a key role, as we 
show in this paper. The most common mechanism is struc¬ 
tural matching, which traverses an input’s structure to check 
whether each of its components match. To make it fast, im¬ 


plementations use variants of hash-consing (e.g., see Filliatre 
[and Conchon] ( |2006[ l) which, in essence, associates with a 
pointer a hash of its contents and compares pointers by hash. 

Structural matching works well when memoizing pure 
computations over immutable data because such computa¬ 
tions always produce the same result. But for IC involving 
mutable references, structural matching can be too specific 
and therefore too fragile. For example, suppose we map a 
function f over a mutable list input = [0,1,3] producing 
output = map f input = [f 0, f 1, f 3]. Next, suppose we mu¬ 
tate input by inserting 2, so input becomes [0,1,2,3]. Finally, 
suppose we recompute map f input, now [f 0, f 1, f 2, f 3], at- 

















tempting to reuse as much of the prior computation as possi¬ 
ble. Structural matching will successfully identify and reuse 
the recursive sub-call map f [3], reusing the result [f 3]. More 
generally, it will reuse the mapped suffix after the inserted 
element, since the computation of this output is independent 
of the mutated prefix. However, structural matching will not 
match the sub-computations that map 0 to f 0 and 1 to f 1 
because these sub-computations’ outputs transitively include 
the newly inserted value of f 2 (via their tail pointers). As a 
result, an IC system that uses structural matching will rerun 
those sub-computations from scratch, recomputing f 0 and 
f 1 and allocating new list cells to hold the results. (Section]^ 
covers this example in detail.) 

The key takeaway is that structural matching is too 
conservative—it was designed for immutable inputs, in 
which case a structural match produces a correct memo- 
ized result. But with IC using mutable inputs, a match need 
not return a correct result; rather, our aim should be to re¬ 
turn a result that requires only a little work to repair. For our 
example, an ideal IC system would be able to memoize the 
prefix, repairing it by mutating the old output cell containing 
f 1 to insert f 2. 

In this paper, we propose to overcome the deficiencies 
of structural matching for IC by employing an alternative 
matching strategy that involves names. We implement our 
solution in NOMINAL Adapton, an extension to the Adap- 
TON IC framework. Our new nominal matching strategy per¬ 
mits the programmer to explicitly associate a name—a first- 
class (but abstract) value—with a pointer such that point¬ 
ers match when their names are equal. A program produces 
names by generating them from existing names or other seed 
values. Returning to our example, we can add names to list 
cells such that an output cell’s name is derived from the 
corresponding input cell’s name. With this change, insertion 
into a list does not affect output cells’ names, and hence we 
can successfully reuse the computation of map on the pre¬ 
fix before the inserted element. The particular naming strat¬ 
egy is explained in detail in Section which also gives an 
overview of the Nominal Adapton programming model 
and shows how it improves performance on the map example 
compared to prior structural approaches. 

Nominal matching is strictly more powerful than struc¬ 
tural matching; The programmer can choose names how¬ 
ever they wish, including mimicking structural matching by 
using hashing. That said, there is a risk that names could 
be used ambiguously, associating the same name with dis¬ 
tinct pointers. In NOMINAL Adapton, if the programmer 
makes a mistake and uses a name ambiguously, efficient run¬ 
time checks detect this misuse and raise an exception. The 
use-once restriction can be limiting, however, so in addition 
to supporting first-class names, NOMINAL Adapton pro¬ 
vides first-class namespaces —the same name can be reused 
as long as each use is in a separate namespace. For exam¬ 
ple, we can safely map different functions over the same list 


by wrapping the computations in separate namespaces. Sec¬ 
tion |3] illustrates several use cases of the Nominal Adap¬ 
ton programming model, presenting naming design pat¬ 
terns for incremental lists and trees and common computa¬ 
tion patterns over them. We also propose a fundamental data 
structure for probabilistically balanced trees that works in a 
variety of applications. 

We have formalized NOMINAL Adapton in a core cal¬ 
culus ANomA and proved its incremental recomputation is 
from-scratch consistent, meaning it produces the same an¬ 
swer as would a recomputation from scratch. As such, mis¬ 
takes from the programmer will never produce incorrect re¬ 
sults. Section|^presents our formalism and theorem. 

We have implemented NOMINAL Adapton in OCaml as 
an extension to Adapton (Section]^. We evaluated our im¬ 
plementation by comparing it to Adapton on a set of sub¬ 
ject programs commonly evaluated in the IC literature, in¬ 
cluding map, filter, reduce, reverse, median, mergesort, and 
quickhull. As a more involved example, we implemented an 
interpreter for an imperative programming language (IMP 
with arrays), showing that interpreted programs enjoy in- 
crementality by virtue of using Nominal Adapton as 
the meta-language. Across our benchmarks, we find that 
Adapton is nearly always slower than Nominal Adap¬ 
ton (sometimes orders of magnitude slower), and is some¬ 
times orders of magnitude slower than from-scratch compu¬ 
tation. By contrast. Nominal Adapton uniformly enjoys 
speedups over from-scratch computation (up to 10900x) as 
well as classic Adapton (up to 21000 x). (Section de¬ 
scribes our experiments.) 

The idea of names has come up in prior incremental com¬ 
putation systems, but only in an informal way. For example, 
|Acar and Ley- Wild] ( |2009[ ) includes a paragraph describing 
the idea of named references (there called “keys”) in the 
DeltaML implementation of SAC. To our knowledge, our 
work is the first to formalize a notion of named computations 
in IC and prove their usage correct. We are also the first to 
empirically evaluate the costs and benefits of programmer- 
named references and thunks. Finally, the notion of first- 
class namespaces, with the same determinization benefits as 
named thunks and references, is also new. (Section [7] dis¬ 
cusses SAC and other related work in more detail.) 


2. Overview 

In this section we present NOMINAL Adapton and its pro¬ 
gramming model, illustrating how names can be used to 
improve opportunities for reuse. We start by introducing 
Adapton’s approach to incremental computation, high¬ 
lighting how Nominal Adapton extends its programming 
model with support for names. Next we use an example, 
mapping over a list, to show how names can be used to im¬ 
prove incremental performance. 






2.1 Adapton and Nominal Adapton 


Co 


Adapton aims to reuse prior computations as much as 
possible after a change to the input. Adapton achieves 
this by memoizing a function call’s arguments and results, 
reusing memoized results when the arguments match (via 
structural matching). In this section, we write memo(e) to 
indicate that the programmer wishes e to be memoizedj^ 
Adapton provides mutable references: ref e allocates a 
memory location p which it initializes to the result of eval¬ 
uating e, and ! p retrieves the contents of that cell. Changes 
to inputs are expressed via reference cell mutations; Adap¬ 
ton propagates the effect of such changes to update pre¬ 
vious results. Like many approaches to incremental com¬ 
putation, Adapton distinguishes two layers of computa¬ 
tion. Computations in the inner layer are incremental, but 
can only read and allocate references, while computations 
in the outer layer can change reference values (necessitat¬ 
ing change propagation for the affected inner-layer compu¬ 
tations) but are not themselves incremental. This works by 
having the initial incremental run produce a demanded com¬ 
putation graph (DCG), which stores values of memoized 
computations and tracks dependencies between those com¬ 
putations and references. Changes to mutable state “dirty” 
this graph, and change propagation “cleans” it, making its 
results consistent. 



(a) Adapton, after insertion update 


ao bo Co do 
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(b) Adapton, after change propagation 


Figure 1: Incremental computation of map in Adapton 


2.2 Incremental Computation in Adapton 

As a running example, consider incrementalizing a program 
that maps over a list’s elements. To support this, we define 
a list data structure that allows the tail to be imperatively 
modified by the outer context: 

type 'a list = Nil | Cons of 'a * ('a list) ref 
let rec map f xs = memo( match xs with 
1 Nil ^ Nil 

I Cons (x, xs) — > Cons (f x, ref (map f Ixs)) ) 

This is a standard map function, except for two twists: the 
function body is memoized via memo, and the input and 
output Cons tails are reference cells. The use of memo here 
records function calls to map, identifying prior calls using 
the function f and input list xs. In turn, xs is either Nil or is 
identihed by a value of type 'a and a reference cell. Hence, 
reusing the identity of references is critical to reusing calls to 
map via memo. Now we can create a list (in the outer layer) 
and map over it (in the inner layer): 

let 13 = Cons(3, ref Nil) (+ 13 = [3] *) 

let II = Cons(l, ref 13) (* II = [1; 3] *) 

let 10 = Cons(0, ref II) (* 10 = [0; 1; 3] *) 

let mO = (* inner start *) map f 10 (* inner end *) 

(+ mO = [f 0; f 1; f 3] =r) 


* Programmers actually have more flexibility thanks to Adapton’s support 
for laziness, but laziness is orthogonal to names, which we focus on in this 
section. We discuss laziness in Sectionpl 


Suppose we change the input to map by inserting an ele¬ 
ment: 

(tl II) := Cons(2. ref 13) (* 10 = [0; 1; 2; 3] *) 

Here, tl returns the tail of its list argument. After this change, 
mO will be updated to [f 0; f 1; f 2; f 3]. In the best case, 
computing mO should only require applying f 2 and insert¬ 
ing the result into the original output. However, Adapton 
performs much more work for the above code. Specihcally, 
Adapton will recompute f 0 and f 1; if the change were 
in the middle of a longer list, it would recompute the entire 
prefix of the list before the change. In contrast. Nominal 
Adapton will only redo the minimal amount of work. 

To understand why, consider Figure [Ta| which illustrates 
what happens after the list update. In this hgure, the ini¬ 
tial input and output lists are shown in black at the top and 
the bottom of the figure, respectively. The middle of the hg¬ 
ure shows the demanded computation graph (DCG), which 
records each recursive call of map and its dynamic depen¬ 
dencies. Here, nodes mapo, mapi, maps and map 4 cor¬ 
respond to the four calls to map. For each call, the DCG 
records the arguments, the result, and the computation’s ef¬ 
fects. Here, the effects are: dereferencing a pointer; making 
a recursive call; and allocating a ref cell in the output list. We 
label the arrows/lines of the hrst node only, to avoid clutter; 
the same pattern holds for mapi and maps. 

In the input and output, the tail of each Cons cell (a 
rounded box) consists of a reference (a square box). The 




























input list is labeled ao, bo, do, and the output list is labeled 
ai, bi, di. In Adapton, structural matching determines the 
labels chosen by the inner layer, and in particular, whenever 
the inner layer allocates a reference cell to hold a value that 
is already contained in an existing reference cell, it reuses 
this first cell and its label. 

After the list is updated, Adapton dirties all the com¬ 
putations that transitively depend on the changed reference 
cell, bo- The dirtied elements are shaded in red. Dirtying 
is how Adapton knows that previously memoized results 
cannot be reused safely without further processing. Adap¬ 
ton processes dirty parts of the DCG into clean compu¬ 
tations on demand, when they are demanded by the outer 
program. To do so, it either re-executes the dirty computa¬ 
tions, or verifies that they are unaffected by the original set 
of changes. 

Figure shows the result of recomputing the out¬ 
put following the insertion change, using this mechanism. 
When the outer program recomputes map f 10 (shown as 
mapo), Adapton will clean (either recompute or reuse) 
the dirty nodes of the DCG. First, it re-executes compu¬ 
tation mapi, because it is the first dirty computation to 
be affected by the changed reference cell. We indicate re- 
executed computations with stars in their DCG nodes. Upon 
re-execution, mapi dereferences bo and calls map on the 
inserted Cons cell holding 2. This new call mapa calls f 
2 (not shown), dereferences co, calls mapa’s computation 
map f (Cons(3,do)), allocates hi to hold its result and re¬ 
turns Cons(f 3, di). 

The recomputation of mapa exploits two instances of 
reuse. First, when it calls map f (Cons(3,do)), Adapton 
reuses this portion of the DCG and the result it computed 
in the first run. Adapton knows that the prior result of 
map f (Cons(3,do)) is unchanged because mapa is not dirty. 
Notice that even if the tail of the list were much longer, the 
prior computation of mapa could still be reused, since the 
insertion does not affect it. 

Second, when mapa allocates the reference cell to hold 
the result of map f (Cons(3,do), i.e. Cons(f 3, di), it reuses 
and shares the existing reference cell hi that already holds 
this content. Notice that this maintains our labeling invari¬ 
ant, so we can continue to perform structural matching by 
comparing labels. As a side effect, it also improves perfor¬ 
mance by avoiding allocation of an (isomorphic) copy of the 


^Note that the outer layer may cause two cells with the same contents 
to be labeled differently: If two cells are initially allocated with different 
contents, but then the outer layer mutates one cell to contain the contents of 
the other, the cells will still have different labels and hence will not match 
in Adapton. This is a practical implementation choice, since otherwise 
Adapton might need to do complicated heap operations to merge the 
identities of two cells. At worst, this choice causes ADAPTON to miss 
some minor opportunities for reuse. However, this choice is consistent with 
the standard implementation of hash-consing, which only aims to share 
immutable structures ^Allen|1978[|Filliatre and Conchon|2006^. 


So far, Adapton has successfully reused subcomputa¬ 
tions, but consider what happens next. When the call map 2 
completes, mapi resumes control and allocates a reference 
cell to hold Cons(f 2, hi). Since no reference exists with 
this content, it allocates a fresh reference xi. New references 
are shown in bold. The computation then returns Cons(f 1, 
xi), which does not match its prior return value Cons(f 1, 
hi). Since this return value has changed from the prior run, 
Adapton re-runs mapi ’s caller, mapo. This consists of re¬ 
running f 0, reusing the (just recomputed, hence no longer 
dirty) computation mapi , and allocating a reference to hold 
its result Cons(f 1, xi). Again, no reference exists yet with 
this content (xi is a fresh tail pointer), so Adapton allo¬ 
cates a fresh cell yj. Finally, the call to mapo completes, 
returning a new list prefix with the same content (f 0 and f 
1) as in the first run, but with new reference cell identities 
(yi andxi). 

In this example, small changes cascade into larger changes 
because Adapton identifies reference cells structurally 
based on their contents. Thus, the entire prefix of the out¬ 
put list before the insertion is reallocated and recomputed, 
which is much more work than should be necessary. 

2.3 The Nominal Approach 

We can solve the problems with structural matching by giv¬ 
ing the programmer explicit names to control reuse. In this 
particular case, we aim to avoid re-computing mapo and 
any preceding computations. In particular, we wish to re¬ 
compute only mapi (since it reads a changed pointer) and to 
compute map 2 , the mapping for the inserted Cons cell. 

The first step is to augment mutable lists with names 
provided by Nominal Adapton; 

type list = Nil I Cons of int + name * (list ref) 

Globally fresh names are generated either non-deterministic- 
ally via new, or from an existing name via fork. In partic¬ 
ular, fork n returns a pair of distinct names based on the 
name n with the property that it always returns the same pair 
of names given the same name n. In this way, the inner layer 
can deterministically generate additional names from a given 
one to enable better reuse. Finally, when the programmer al¬ 
locates a reference cell, she explicitly indicates which name 
to use, e.g. ref(n,l) instead of ref(l). 

Now, when the list is created, the outer layer calls new to 
generate fresh, globally distinct names for each Cons cell; 

let 13 = Cons(3, new, ref(new, Nil)) (=i< 13 = [3] "t) 

let II = Cons(l, new, ref(new, 13 )) (* II = [1; 3] *) 

let 10 = Cons(0, new, ref(new, II )) (♦ 10 = [0; 1; 3] *) 

When the inner layer computes with the list, it uses the 
names in each Cons cell to indicate dependencies between 
the inputs and outputs of the computation. In particular, we 
rewrite map as follows; 
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(a) Nominal Adapton, after insertion update 


ao bo Co do 



(b) Nominal Adapton, after change propagation 


Figure 2: IC of map with Nominal Adapton 


let rec map f xs = memo( match xs with 
1 Nil ^ r 
j Cons(x, nm, xs) 

let nml, nm2 = fork nm in 
Cons(f X, nml, ref (nm2, map f (Ixs))) ) 

Unlike the outer program, which chooses reference names 
using new, the inner program uses fork to relate the names 
and references in the output list to the names in the input list. 

Now consider applying this function and making the 
same change as above: 

let mO = map f 10 in 

(tl II) := Cons(2, new, ref 13) 

Figurej^shows what happens. The initial picture in Figure[2a] 
is similar to the structural case in Figure except the 
input and output lists additionally contain names ao, |3o,yo 
and § 0 . The first part of the recomputation is the same: 
Nominal Adapton recomputes mapi, which reads the 
mutated reference bo. In turn, it recomputes map 2 , which 
reuses the call to mapa to compute Cons(f 2, yi, cj). The 
recomputation of map 2 returns a different value than in the 
prior run, with the new head value f 2. 

At this point, the critical difference occurs. Even though 
the result of map 2 is distinct from any list in the prior run, the 
call mapi allocates the same ref cell bo as before, because 
the name it uses for this allocation, (3 1 , is the same as before. 
In the figure, fork po > (Pi,Pi), where pi becomes the 
name in the output list and bi = ref p 2 identifies the 
reference cell in its tail. NOMINAL Adapton dirties the 
reference bi, to ensure that any dependent computations will 


be cleaned before their results are reused. Due to this reuse, 
the result of the call mapi is identical to its prior result: The 
value of f 1 is unaffected, and the tail pointer bi was reused 
exactly. Next, NOMINAL Adapton examines mapo and all 
prior calls. Because the return value of mapi did not change. 
Nominal Adapton simply marks the DCG node for its 
caller, mapo, as clean; no more re-evaluation occurs. This 
cleaning step breaks the cascade of changes that occurred 
under Adapton. Prior computations are now clean, because 
they only depend on clean nodes. 

As a result of this difference in behavior. Nominal 
Adapton is able to reuse all but two calls to function f 
for an insertion at any index i, while Adapton will gener¬ 
ally re-execute all i — 1 calls to function f that precede the 
inserted cell. Moreover, Adapton allocates a new copy of 
the output prefix (from 0 to i), while NOMINAL Adapton 
reuses all prior allocations. Our experiments (Section]^ con¬ 
firm that these differences make Adapton over 10 x slower 
than Nominal Adapton, even for medium-sized lists (10k 
elements) and cheap instances of f (integer arithmetic). 

2.4 Enforcing that Nominal Matching is Correct 

Putting the task of naming in the programmer’s hands can 
significantly improve performance, but opens the possibility 
of mistakes that lead to correctness problems. In particular, 
a programmer could use the same name for two different 
objects: 

let y = ref n 1 

let z = ref n false 

Double use leads to problems since the variables y and z have 
distinct types, yet they actually reference the same nominal 
object, the number or boolean named n. Consequently, the 
dereferenced values of y and z are sensitive to the order of 
the allocations above, where the last allocation “wins.” This 
imperative behavior is undesirable because it is inconsistent 
with our desired from-scratch semantics, where allocation 
always constructs new objects. 

To forbid double use errors, our implementation uses an 
efficient dynamic check. As the DCG evolves during pro¬ 
gram execution. Nominal Adapton maintains a stack of 
DCG nodes, its force stack, which consists of those DCG 
nodes currently being forced (evaluated, re-evaluated, or 
reused). When nominal matching re-associates a name with 
a different value or computation than a prior usage, it over¬ 
writes information in the DCG, and it dirties the old use 
and its transitive dependencies in the DCG. To check that 
a nominal match is unambiguous, we exploit a key invari¬ 
ant: A name is used ambiguously by a nominal match if and 
only if one or more DCG nodes on the force stack are dirt¬ 
ied when said nominal match occurs. If no such node exists, 
then the name is unambiguous. Nominal Adapton im¬ 
plements this check by maintaining, for each DCG node, a 
bit that is set and unset when the node is pushed and popped 
































































from the force stack, respectively. This implementation is 
very efficient, with 0(1] overhead. 

Returning to the example above, the allocation of z nom¬ 
inally matches the allocation on the prior line, for y. Since 1 
and false are not equal, the nominal match dirties the DCG 
node that allocates 1, which is also the “current” DCG node, 
and thus is on the top of the force stack. Hence, NOMINAL 
Adapton raises an exception at the allocation of z, indicat¬ 
ing that n is used ambiguously. 

Note that because this check is dynamic and based on the 
DCG, it works even when ambiguous name uses are sepa¬ 
rated across function or module boundaries. This is impor¬ 
tant since, in our experience, most name reuse errors are 
not nearly as localized as the example above. This dynamic 
check was essential for our own development process; with¬ 
out it, nominal mistakes were easy to make and nearly im¬ 
possible to diagnose. 

2.5 Namespaces 

Unfortunately, forbidding multiple uses of names altogether 
prevents many reasonable coding patterns. For example, 
suppose we want to map an input list twice: 

let ys = map f input_list 
let zs = map g input_list 

Recall that in the Cons case of map we use each name in the 
input list to create a corresponding name in the output list. 
As such, the two calls to map result in ys and zs having cells 
with the same names, which is forbidden by our dynamic 
check. 

We can address this problem by creating distinct names¬ 
paces for the distinct functions (f versus g), where the same 
names in two different namespaces are treated as distinct. A 
modified version of map using namespaces would be written 
thus: 

let map' n h xs = nest(ns(n), map h xs) 

The code nest(s,e) performs the nested computation e in 
namespace s, and the code ns(n) creates a namespace from 
a given name n. Just as with references, we must be care¬ 
ful about how namespaces correspond across different in¬ 
cremental runs, and thus we seed a namespace with a given 
name. Now, distinct callers can safely call map’ with distinct 
names: 

let nl, n2 = (new, new) in 
let xs = map' nl f input_list in 
let ys = map' n2 g input_list in 

The result is that each name in the input list is used only once 
per namespace: Names in map f will be associated with the 
first namespace (named by nl), and names in map g will 
associate with the second namespace (named by n2). 

Section summary. The use of names allows the program¬ 
mer to control (1) how mutable reference names are chosen 
the first time, and (2) how to selectively reuse and overwrite 


these references to account for incremental input changes 
from the outer layer. These names are transferred from in¬ 
put to output through the data structures that they help iden¬ 
tify (the input and output lists here), by the programs that 
process them (such as map). Sometimes we want to use the 
same name more than once, in different program contexts 
(e.g., map f • versus map g •); we distinguish these program 
contexts using namespaces. 


3. Programming with Names 

While Nominal Adapton’s names are a powerful tool for 
improving incremental reuse, they create more work for the 
programmer. In our experience so far, effective name reuse 
follows easy-to-understand patterns. Section 3.1 shows how 
to augment standard data structures—lists and trees—and 
operations over them—maps, folds, and unfolds—to incor¬ 
porate names in a way that supports effective reuse. Sec¬ 
tion 3.2 describes probabilistic tries, a nominal data struc¬ 


ture we developed that efficiently implements incremental 
maps and sets. Finally, Section 3.3 describes our implemen¬ 
tation of an incremental IMP interpreter that takes advantage 
of these data structures to support incremental evaluation of 
its imperative input programs. The benefits of these patterns 
and structures are measured precisely in Section]^ 


3.1 General Programming Patterns 

Practical functional programs use a wide variety of program¬ 
ming patterns; three particularly popular ones are mapping, 
folding, and unfolding. We consider them here in the context 
of lists and trees. 


Mapping. Maps traverse a list (as in Section]^ or tree and 
produce an output structure that has a one-to-one correspon¬ 
dence with the input structure. We have already seen how 
to incrementalize mapping by associating a name with each 
element of the input list and using fork to derive a corre¬ 
sponding name for each element in the output list, thereby 
avoiding spurious recomputation of whole list prefixes on a 
change. 

Folding. Folds traverse a list or tree and reduce subcompu¬ 
tations to provide a final result. Examples are summing list 
elements or finding the minimum element in a tree. 

If we implement folding in a straightforward way in 
Nominal Adapton, the resulting program tends to per¬ 
form poorly. The problem is that every step in a list-based 
reduction uses an accumulator or result that induces a global 
dependency on all prior steps—i.e., every step depends on 
the entire prefix or the entire suffix of the sequence, meaning 
that any change therein necessitates recomputing the step. 

The solution is to use an approach from parallel program¬ 
ming: Use trees to structure the input data, rather than lists, 
to permit expressing independence between sub-problems. 
Consider the following code, which defines a type tree for 
trees of integers: 





type tree = Leaf j Bin of name * int * (tree ref) * (tree ref) 

Like lists, these trees use refs to permit their recursive struc¬ 
ture to change incrementally, and each tree node includes a 
name. We can reduce over this tree in standard functional 
style: 

let tree_min tree = memo(match tree with 
I Leaf —> maxjnt 

I Bin(n,x,l,r) —> min3(x, tree_min(!l), tree_min(!r))) 

If we later update the tree and recompute, we can reuse sub¬ 
tree minimum computations, because the names are stable in 
the tree. 

Below, we show the original input tree alongside two 
illustrations (also depicted as trees) of which element of 
each subtree is the minimum element, before and after the 
replacement of element 1 with the new element 9: 


Original tree 

Minimums 

(pre-change) 

Minimums 

(post-change) 

14-6 

14-6 

9 4-6 

V “V 

\/ \/ 

\/ V 

2 5 

1 5 

2 5 

3 

1 
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Notice that while the hrst element 1 changed to 9, this 
only affects the minimum result along one path in the tree: 
the path from the root to the changed element. In contrast, if 
we folded the sequence naively as a list, all the intermediate 
computations of the minimum could be affected by a change 
to the hrst element (or last element, depending on the fold 
direction). By contrast, the balanced tree structure (with ex¬ 
pected logarithmic depth) overcomes this problem by better 
isolating independent subcomputations. 

Pleasingly, as hrst shown by Pugh and Teitelbaum (19891, 
we can efficiently build a tree probabilistically from an input 
list, and thus transfer the benehts of incremental tree reuse 
to list-style computations. Building such a tree is an example 
of unfolding, described next. 


Unfolding. Unfolds iteratively generate lists or trees us¬ 
ing a “step function” with internal state. As just mentioned, 
one example is building a balanced tree from a list. Unfortu¬ 
nately, if we implement unfolding in a straightforward way, 
incremental computation suffers. In particular, we want sim¬ 
ilar lists (related by small edits) to lead to similar trees, with 
many common subtrees; meanwhile, textbook algorithms for 
building balanced trees, such as AVL trees and splay trees, 
are too sensitive to changes to individual list elements. 

The solution to this problem is to construct a probabilisti¬ 
cally balanced tree, with expected O (log n) height for input 
list n. The height of each element in the resulting tree is 
determined by a function that counts the number of trailing 
zero bits in a hash of the given integer. For example, given in¬ 
put elements [a, b, c, d, e, f] with heights [0,1,0,2,1,0], re¬ 


spectively, then our tree-construction function will produce 
the binary tree shown below: 

Q c • f 

^ V 

b e 

d 

[Pugh and Teitelbaum| ( |1989] l showed that this procedure 
induces a probabilistically balanced tree, with similar lists 
inducing similar trees, as desired. Further, each distinct list 
of elements maps to exactly one tree structure. This property 
is useful in NOMINAL Adapton, since a canonical struc¬ 
ture is more likely to be reused than one that can exhibit 
more structural variation. While past work has considered 
incremental computations over such balanced trees, in this 
work we find that the construction of the tree from a muta¬ 
ble, changing sequence can also be efficiently incremental- 
ized (Pugh’s work focused only on a pure outer program). 

3.2 Probabilistic Tries 

Inspired by probabilistic trees, we developed efficient, in¬ 
cremental probabilistic tries, which use a different naming 
pattern in which certain names are external to the data struc¬ 
ture. 

We dehne tries as binary trees whose nodes hold a name 
and two children (in reference cells), and whose leaves store 
data. Here we use integers for simplicity, but in general 
nodes would hold arbitrary data (e.g., for maps, they would 
hold key-value pairs): 

type trie = Nil 

I Leaf of int 

I Bin of name * (trie ref) * (trie ref) 

The key idea of a probabilistic trie is to use a bit string 
to identify two things at once: the element stored in the 
structure (via its hash) and the path to retrieve that element, 
if it is present. To keep it simple, the code below assumes 
that all data elements have a unique hash, and that the input 
trie is complete, meaning that all paths are dehned and either 
terminate in a Nil or a Leaf. Our actual implementation of 
tries makes neither assumption. 

The hrst operation of a trie is find, which returns either 
Some data element or None, depending on whether data with 
the given hash (a list of bools) is present in the trie. 

val find : trie —> bool list int option 

let rec find trie bits = 
match bits, trie with 
I [], Leaf(x) —I Some x 
I [], Nil —> None 

I true::bits, Bin(_,left,right) —^ find (Heft) bits 
I false::bits, Bin(_,left,right) —> find (Iright) bits 

The other operation on tries is extend n t b d which, given 
an input trie t, a data element d and its hash b, produces a 
new trie with d added to it: 














val extend : name trie bool list —> int trie 

let rec extend nm trie bits data = memo ( 
match bits, trie with 
I [], (Leaf _ I Nil) Leaf(x) 

I false;:bits, Bin(_,left,right) (* symmetric to below *) 

I true::bits, Bin(_,left,right) 

let nl, n2, n3, n4 = fork4 nm in 
let right' = extend nl (Iright) bits data in 
Bin(n2, ref(n3. Meft), ref(n4, right')) ) 

Critically, the first argument to extend is an externally 
provided nm that is used to derive names (using fork) for 
each ref in the new path. Thus, the identity of the trie re¬ 
turned by extend n t b d only depends directly on the name n 
and the inserted data, and not on the names or other content 
of the input trie t. 

Any incremental program that sequences multiple trie 
extensions makes critical use of this independence (e.g., 
the interpreter discussed below). To see how, consider two 
incremental runs of such a program with two similar se¬ 
quences of extensions, [1,2,3,4,5,6] versus [2,3,4,5,6], 
with the same sequence of hve names for common ele¬ 
ments [2,..., 6]. Using the name-based extension above, the 
tries in both runs will use exactly the same reference cells. 
By contrast, the structural approach will build entirely new 
tries in the second run, since the second sequence is missing 
the leading 1 (a different initial structure). Similarly, using 
the names in the trie to extend it will also fail here, since 
it will effectively identify each extension by a global count, 
which in this case shifts by one for every extension in the 
second run. Using external names for each extension over¬ 
comes both of these problematic behaviors, and gives maxi¬ 
mal reuse. 

3.3 Interpreter for IMP 

Finally, as a challenge problem, we used Nominal Adap- 
TON to build an interpreter for IMP ( |Winskel|1993| l, a sim¬ 
ple imperative programming language. Since our interpreter 
is incremental, we can efficiently recompute an interpreted 
program’s output after a change to the program code it¬ 
self. While Adapton requires incrementalized computations 
to be fully functional, implementing a purely functional in¬ 
terpreter for IMP allows the imperative object language to 
inherit the incrementality of the meta-language. 

The core of our interpreter is a simple, big-step eval 
function that recursively evaluates an IMP command in some 
store (that is, a heap) and environment, returning the hnal 
store and environment. 

Commands include while loops, sequences, conditionals, 
assignments (of arithmetic and boolean expressions) to vari¬ 
ables, and array operations (allocation, reading, and writing). 
All program values are either booleans or integers. As in 
C, an integer also doubles as a “pointer” to the store. The 
interpreter uses hnite maps to represent its environment of 
type env (a mapping from variables to infs) and its store of 
array content (a mapping from ints to ints). 


For incremental efficiency, the interpreter makes critical 
use of the programming patterns we have seen so far. We use 
probabilistic tries to represent the hnite maps for stores and 
environments. Each variable assignment or array update in 
IMP is implemented as a call to extend for the appropriate 
trie. Names have two uses inside the interpreter. Each call 
to extend requires a name, as does each recursive call to 
eval. Classic Adapton would identify each with the full 
structural content of its input. Eor the IMP language, we 
require far less information to disambiguate one program 
state from another. 

Consider hrst the IMP language without while loops. 
Each subcommand is interpreted at most once; as such, each 
program state and each path created in the environment or 
store can be identihed with the particular program position 
of the subcommand being interpreted. 

With the addition of while loops, we may interpret a sin¬ 
gle program position multiple times. To disambiguate these, 
we thread loop counts through the interpreter represented as 
a list of integers. The loop count [3,4], for example, tells us 
we are inside two while loops; the third iteration through the 
inner loop, within the fourth iteration through the outer loop. 
We extend the NOMINAL Adapton API to allow creating 
names not just by forking, but also by adding in a count— 
here, names are created using the loop count paired with 
the name of the program position. As such, the names suffi¬ 
ciently distinguish recursive calls to the interpreter and paths 
inside the environment and store. 

val eval : nm * int list * store * env * cmd ^ store * env 

In our experiments, we show that the combination of 
this naming strategy and probabalistically balanced tries 
yields an efficient incremental interpreter. Moreover, the in¬ 
terpreter’s design provides evidence that Nominal Adap- 
TON’s programming patterns are compositional, allowing us 
to separately choose how to use names for different parts of 
the program. 

4. Formal Development 

The interaction between memoization, names, and the de¬ 
manded computation graph is subtle. Eor this reason, we 
have distilled Nominal Adapton to a core calculus 
called A|\iomA. which represents the essence of the NOMI¬ 
NAL Adapton implementation and formalizes the key al¬ 
gorithms behind incremental computation with names. We 
prove the fundamental correctness property of incremental 
computation, dubbed/rom-icrafch consistency, which states 
that incrementally evaluating a program produces the same 
answer as re-evaluating it from scratch. This theorem also 
establishes that (mis)use of names cannot interfere with the 
meaning of programs; while a poor use of names may have 
negative impact on performance, it will not cause a program 
to compute the wrong result. 




We present the full theory but only sketch the consistency 
result here; the details and proofs are in the extended version 
of this paper ( Hammer et al.|20T5] l. 

The formal semantics presented here differs consider¬ 


ably from that of the original Adapton system (Hammer 


|et al.|[20T4l l. In particular, the original semantics modeled 
the DCG as an idealized cache of tree-shaped traces that re¬ 
member all input-output relationships, forever. In contrast, 
the one developed here models the DCG as it is actually im¬ 
plemented in both Adapton and Nominal Adapton, as 
a changing graph whose nodes are memoized refs and mem- 
oized computations (thunks), and whose edges are their de¬ 
pendencies. Further, via names, this semantics permits more 
kinds of DCG mutation, since the computations and val¬ 
ues of a node can be overwritten via nominal matching. In 
summary, compared to the prior semantics, our theory more 
accurately models the implementation, and our metatheory 
proves correctness in a more expressive setting. 


Graphs 
G,H ::= £ 

G,p:v 
G,p:e 
G,p:(e,t) 
G,(p,a,b, q) 


empty graph 
p points to value v 

p points to thunk e (no cached result) 
p points to thunk e with cached result t 
p depends on q due to action a, 
with status b 


Edge actions 
a ::= 

alloc V 
I alloc e 
I obsv 
I obst 


For edge (p, a, b, q), the computation at p... 
... created reference v at q 
... created thunk e at q 
... read q’s value, which was v 
... forced thunk q, which returned t 


Edge statuses 

b ::= clean value or computation at sink is out of date 
I dirty value or computation at sink is up to date 


Figure 4; Graphs 


Pointers p, q 

:= k@a) root 

Names k 

:= • 1 k-1 1 k-2 

Namespaces cu, p 

:= T 1 cu.k 


Values V 

:= X 1 (vi,V2) 


1 inji V 



nmk 

name 


1 ref p 

pointer to value (reference cell) 


1 thkp 

pointer to computation 


nso) 

namespace identifier 


Results 

t ::= Ax.e | retv 


Computations 

e ::= t I ev I f I flxf.e I letxi— Cl in ez 

I case (v,xi .ei ,X2.e2) | split (v,xi .X2.e) 
thunk(v,e) create thunk e at name v 

force (v) force thunk that v points to 

fork(v) fork name v into two halves v-1, v-2 

ref{ V], V2) allocate V2 at name vi 

get (v) get value stored at pointer v 

ns(v,x.e) bind X to a new namespace V 

nest(v, 0 ], x.e2) evaluate e in namespace v 
and bind x to the result 


Figure 3; Syntax 


4.1 Syntax 

The syntax of A|\iomA is defined in the style of the call-by- 
push-value (CBPV) calculus ( Levy|[T999l ), a standard vari¬ 
ant of the lambda calculus with an explicit thunk mecha¬ 
nism. Figure gives the syntax of the language. The non- 
highlighted features are standard, and the highlighted forms 
are new in AiMomA- 

Nominal Adapton follows Adapton in supporting 
demand-driven incremental computation using a lazy pro¬ 
gramming model. In Adapton, programmers can write 
thunk(e] to create a suspended computation, or thunk. The 


thunk v’s value is computed only when it is forced, using 
syntax force(v). Thunks also serve as Adapton’s (and 
Nominal Adapton’s) unit of incremental reuse: if we 
want to reuse a computation, we must make a thunk out 
of it. The syntax memo(e) we used earlier is shorthand for 
force(thunk(e, e)), where we abuse notation and treat e as 
a name that identifies itself^This construction introduces 
a thunk that the program immediately forces, eliminating 
laziness, but supporting memoization. 

CBPV distinguishes values, results (or terminal compu¬ 
tations), and computations. A computation e can be turned 
into a value by thunking it via thunk(v, e). The first argu¬ 
ment, the name v, is particular to NOMINAL Adapton; or¬ 
dinary CBPV does not explicitly name thunks. Conversely, 
a value v can play the role of a result t via ret v; results t are 
a subclass of computations e. 

Functions Ax.e are terminal computations; ev evaluates 
e to a function Ax.e' and substitutes v for e'. Note that the 
function argument in e v is a value, not a computation. 

Let-expressions letx<— eiinei evaluate the computa¬ 
tion ei first. The usual A-calculus application e^ ez can be 
simulated by letx<— 62 in (ei x). Fixed points flxf.e are 
computations, and so are fixed point variables f. 

Given an injection into a disjoint union, inj^ v, the case 
computation form eliminates the sum and computes the cor¬ 
responding Ci branch, with v substituted for x^. Given a pair 
(vi, V 2 ), the computation split (v, Xi .X 2 .e) computes e, first 
substituting vj for xi, and V 2 for X 2 . 

For more on (non-nominal, non-incremental) formula¬ 
tions of CBPV, including discussion of value types and com¬ 
putation types, see |Levy| ( |1999||200T] l. 

Graphs, Pointers, and Names. Graphs G are defined in 
Figure They represent the mutable store (references), 

^Notice that NOMINAL ADAPTON thunks are also named, which provides 
greater control over reuse. 


















memo tables (which cache thunk results), and the DCG. Ele¬ 
ment p:v says that pointer p’s curi'ent value is v. Element p:e 
says that pointer p is the name of thunk e. Element p:(e, t) 
says that p is the name of thunk e with a previously com¬ 
puted result t attached. Element (p, a, b, q] is a DCG edge 
indicating that the thunk pointed to by p depends on node q, 
where q could either name another thunk or a reference cell. 
Dependency edges also reflect the action a that produced the 
edge and the edge’s status b (whether it is clean or dirty). 

Pointers in ANomA are represented as pairs k@cuj^ where 
nmk was the name given as the first argument in a call to 
thunk or ref, and tu was the namespace in which the call to 
thunk or ref took place. This namespace tu is either T for 
the top-level, or some p.ki as set by a call to nest. Eor the 
latter case, the program would hrst construct a value ns p.ki 
by calling ns with first argument nm ki while in namespace 
p. Notice that pointers and namespaces have similar struc¬ 
ture, and similar assurances of determinism when creating 
named thunks, references, and namespaces. Einally, names 
k consist of the root name •, while other names are created 
by “forking” existing names: invoking fork(nm k) produces 
names nmk l and nmk-2. 

4.2 Semantics 

We dehne a big-step operational semantics (Eigure|^ with 
judgments Gi hj|l, e JJ- Gait, which states that under 
input graph Gi and within namespace cu, evaluating the 
computation e produces output graph G 2 and result t, where 
e’s evaluation was triggered by a previous force of thunk p. 

Incremental and Reference Systems. In order to state and 
later prove our central meta-theoretic result, from-scratch 
consistency, we dehne two closely-related systems of eval¬ 
uation rules: an incremental system and a non-incremental 
or reference system. The incremental system models NOM¬ 
INAL Adapton programs that transform a graph whose 
nodes are store locations (values and thunks) and whose 
edges represent dependencies (an edge from p to q means 
that q depends on p); the reference system models call-by- 
push-value programs under a plain store (a graph with no 
edges). Since it has no 1C mechanisms, everything the refer¬ 
ence system does is, by dehnition, from-scratch consistent. 

Rules above the double horizontal line in Eigure|^do not 
manipulate the graph, and are common to the incremental 
and reference systems. The shaded rules, to the left of verti¬ 
cal double lines, are non-incremental rules that never create 
edges and do not cache results. The rules to their right create 
edges, store cached results, and recompute results that have 
become invalid. 

4.2.1 Common Rules 

Several of the rules at the top of Eigure|^are derived from 
standard CBPV rules. 

^The pointer root is needed to represent the top-level “thunk” in the 
semantics, but will never be mapped to an actual value or expression. 


Rules for standard language features (pairs, sums, func¬ 
tions, fix, and let) straightforwardly adapt the standard rales, 
ignoring p and cu and “threading through” input and output 
graphs. Eor example, Eval-app evaluates a function e^ to get 
a terminal computation Ax.ei and substitutes the argument 
V for X, threading through the graph: evaluating ei produces 
Gi, which is given as input to the second premise, resulting 
in output graph G 3 . Rule Eval-case, applying case to a sum 
inj^ V, substitutes v for xt in the appropriate case arm. 

The last three shared rules are not standard: they deal with 
names and namespaces. 

• Eval-fork splits a name k into children k l and k-2. Once 
forked, the name k should not be used to allocate a new 
reference or thunk, nor should k be forked again. 

• Running in namespace cu, Eval-namespace makes a new 
namespace cu.k and substitutes it for x in the body e. 

• Running in namespace cu, Eval-nest runs ei in a different 
namespace p. and then returns to cu to rxin 62 , with x 
replaced by the result of running 6 ]. 

4.2.2 Non-incremental Rules 

These rales cover allocation and use of references and 
thunks. Like the incremental rules (discussed below), they 
use names and namespaces; however, they do not cache the 
results of thunks. We discuss the non-incremental rules first, 
because they are simpler and provide a kind of skeleton for 
the incremental rules. 

• Eval-refPlain checks that the pointer described by q = 
k@cu is fresh (q ^ domjGi)), adds a node q with 
contents v to the graph (Gl{q^—>v} = G 2 ), and returns 
a reference ref q . 

• Eval-thunkPlain is similar to Eval-refPlain, but creates a 
node with a suspended computation e instead of a value. 

• Eval-getPlain returns the contents of the pointer q. 

• Eval-forcePlain extracts the computation stored in a 
thunk (Gi (q) = e) and evaluates it under the names¬ 
pace of q; that is, if q = k@|j., it evaluates it under p. 
(The rule uses namespace(k@p) = p). 

4.2.3 Incremental Rules 

Each non-incremental rule corresponds to one or more incre¬ 
mental rules: the incremental semantics is influenced by the 
graph edges, which are not present in the non-incremental 
system. Eor example, Eval-refPlain is replaced by Eval- 
refDirty and Eval-refClean. 

These rules use some predicates and operations, such as 
dirty-paths-in, that we explain informally as we describe the 
rales; they are fully dehned in Pigure|^ 

Incremental computation arises by making Gi a modi¬ 
fication of a previously produced graph G 2 , and then re¬ 
running e. A legal modification involves replacing refer¬ 
ences p:v with p:v' and dirtying all edges along paths to p in 



G 1 l“IIi e 41 G 2 ; t Under graph G 1 , evaluating expression e as part of thunk p in namespace cu yields G 2 and t. 


Rules common to the non-incremental and incremental systems: 


G l-P G;t 

Gi hP [(flxf.e)/f]e 4 G 2 ;t 
G] flxf.e G 2 ;t 

Gi l-J^ [v/x,]e,- 4 |, G 2 ;t 
Gi l-P case(inj^v,xi.ei,x2.e2) G2;t 


Eval-term 


Gi hJL C] U G2;Ax.e2 
Gz I-IL [v/x]e2 4 G3;t 
Gi Cl V GaU 


Eval-app 


Eval-fix 


Eval-case 


Eval-bind 


G fork(nmk) 4 G;ret (nmk-l, nmk-2) 


Gi l-P 6] G2;retv 
G 2 klL [v/x]e 2 4 GaU 
Gi letxt— C] in 62 Ga;t 

Gi kJL [vi/x,][v2/x2]e41-G2;t 

Gi 1 - 44 , split((vi,V 2 ),xi.X 2 .e) G 2 ;t 
Eval-fork 


Eval-split 


Gi 1-14, [nsai.k/x]e U G 2 ;t 
G] hH, ns{nmk,x.e) G 2 ;t 


Eval-namespace 


Gi 1-14 61 44 G 2 ;retv G 2 kH [v/x]e 2 44 Ga;t 
Gi hH nest(ns p, 61 ,x. 62 ) 44 Ga;t 


Eval-nest 


Rules specific to the (non-incremental || incremental) systems: 


q = k@a) 

q^dom(Gi) Gi{qi-^v} = G 2 
Gi I-14, ref(nmk,v) 44 G 2 ;retref q 


Eval-refPlain 


q=k@tu Gi{qi-^v}=G 2 dirty-paths-in(G 2 , q) = Ga 

- Eva I-ref Dirty 

Gi I-14, ref(nmk,v) 44 Ga, (p,alIocv,clean, q);retref q 


q = k@tu G(q) = v 

G hH ref(nmk, v) 44 G, (p, allocv, clean, q);retref q 


Eval-refClean 


q = k@a) 

q^dom{Gi) Gi{qi-^e} = G 2 ^ . 

-Lval-thunkPlain 

G 1 hH thunk(nmk, e) 44 G 2 ; ret (thk q) 


q = k@tu Gi{qi—>e} = G2 dirty-paths-in(G2, q) = Ga 

-Eval-thunkDirty 

Gi 1-14, thunk{nmk, e) 44 Ga, (p,alloc 6 , clean, q);ret (thk q) 

q=k@tu exp(G,q) = e 

•-Eva l-t h u n kC lea n 

G 1-14, thunk(nmk, e) 44 G, (p, alloc 6 , clean, q);ret (thk q) 


_G(q) = V_ 

G kH get (ref q) 44 G; retv 


Eval-getPlain 


_G(q) = V_ 

G kl4, get (ref q) 44 G, (p, obsv, clean, q);retv 


Eval-getClean 


G(q) = (e,t) all-clean-out(G, q) 

G kl4 force (thk q) 44 G, (p,ohst, clean, q);t 


Eval-forceClean 


Gi(q) = e 

Gi e4l- G 2 ;t 

Gi kl4, force (thk q) 44 Ga’.t 


Eval-forcePlain 


all-clean-out((Gi, G 2 ), qa) 
consistent-action((Gi, Ga), Q, qa) 

Gi, (qi, a,clean, qa), Ga kl4 force (thkpo) 44 Ga;t 
Gi,(qi,a,dirty, q 2 ),G 2 kl4, force(thkpo) 44 Ga;t 


Eval-scrubEdge 


exp{Gi,q)=e' G 2 {qi-^(e',t')} = G4 

del-edges-out(Gi{qi-^e^}, q) = Gj all-clean-out(G 2 , q) 
Gikl,,,^ 3 ,,(^)e' 4 Ga;t' _ Gj kH force (thkpo) 4 Ga;t 


Gi kl4 force (thkpo) 44 Ga;t 


Eval-computeDep 


Figure 5: Evaluation tTiles of A|\iomA; vertical bars separate non-incremental rules (left, shaded) from incremental rules (right) 


































exp(G,p)=e if G(p) = e or G(p) = (e, t) 

G{pi—>v} = G' 

where, if p ^ dom(G), then G' = (G,p:v) 

otherwise, if G = (G] ,p:v', Gi) then G' = [G] ,p:v, Gi) 

G{pi—>e} = G' 

where, if p ^ dom(G), then G' = (G,p:e) 
otherwise, if G = [G] ,p:e', Gi) or G = (Gj ,p:(e', t'), Gi) 
then G' = (Gi ,p:e, G2) 

G{pi-^(e,t)} = G' 

where, if p ^ dom(G), then G' = (G,p:(e, t)) 
otherwise, if G = [G] ,p:e', Gi) or G = (Gj ,p:(e', t'), G2) 
then G' = (Gi, p:(e, t), G2) 

all-clean-out(G,p) = V(p, a, b, q) S G. (b = clean) 

(del-edges-out(Gi ,p) = G2) = 

(nodes(Gi) = nodes(G2)) 

andVq ^p. ((q,Q,b,q') e Gi) => ((q,a,b,q') e G2) 
and $a, b, q. (p, a, b, q) S G2 

(dirty-paths-in(Gi ,p) = G2) = 

(nodes(Gi) = nodes(G2)) 

andVqi,q2. ((qi, a, b', q2) S G2) => ((qi,a,b,q2) S Gi) 
andVqi,q 2 . ((qi,Q,b,q 2 ) S Gi) ^ 
there exists (qi,Q, G G2 such that 

if path(q2,p, Gi) then — dirty) else (b^ — b] 

path{p,q,G) = ((p, a, b, q) e G) 

or ( 3 p'. ((p, a, b,p') S G) and path(p', q, G)) 

consistent-action(G, a, q): 

consistent-action(G, obsv, q) when G(q) = v 
consistent-action(G,obst, q) when G(q) = (e,t) 
consistent-action(G, allocv, q) when G(q) = v 
consistent-action(G, alloce, q) when G(q) = e 

Figure 6; Graph predicates and transformations 

the DCG; dirty-paths-in(Gi ,p) is the same as Gi but with 
edges on paths to p marked dirty. 

Creating Thunks. The DCG is constructed during evalua¬ 
tion. The main rule for creating a thunk is Eval-thunkDirty, 
which converts computation e into a thunk by generating 
a pointer q from the provided name k, which couples the 
name with the current namespace tu. The output graph is 
updated to map q to e. If q happens to be in the graph al¬ 
ready, all paths to it will be dirtied. Finally, the rule adds 
edge (p, alloc e, clean, q) to the output graph, indicating that 
the currently evaluating thunk p depends on q and is cur¬ 
rently clean. 

Forcing Thunks. Forcing a thunk that has not been previ¬ 
ously computed, an operation that involves one rule in the 
non-incremental system (Eval-forcePlain), involves at least 
two rules in the incremental system: Eval-computeDep and 
Eval-forceClean. 

Rule Eval-forceClean performs memoization: Given q 
pointing to (e, t), where t is the cached result of the thunk 
e, if q’s outgoing edges are clean then t is consistent and 
can be reused. Thus Eval-forceClean returns t immediately 
without reevaluating e, but adds an edge denoting that p has 
observed the result of q to be t. 


Rule Eval-computeDep applies when e = force (thkpo). 
This rule serves two purposes: it forces thunks for the first 
time, and it selectively recomputes until a cached result can 
be reused. 

Its first premise exp(Gi,q) = e' nondeterministically 
chooses some thunk q whose suspended expression is e' 
(whether or not q also has a cached result). Its second 
premise del-edges-out(Gi{qi—>e'}, q) = Gj updates Gi so 
that q points to e' (removing q’s cached result, if any), and 
deletes outward edges of q. We need to delete the outward 
edges before evaluating e' because they represent what a 
previous evaluation of e' depended on. The third premise re¬ 
computes q’s expression e', with q as the current thunk and 
q’s namespace component as the current namespace. In the 
fourth premise, the recomputed result t' is cached, resulting 
in graph G^. 

The final premise evaluates force (thkpo), the same ex¬ 
pression as the conclusion, but under a graph G 2 contain¬ 
ing the result of evaluating e'. In deriving this premise we 
may again apply Eval-computeDep to “fix up” other nodes 
of the graph, but will eventually end up with the thunk q 
chosen in the first premise being po itself. In this case, the 
last premise of Eval-computeDep will be derived by Eval- 
forceClean (with q instantiated to po). 

We skipped the fifth premise all-clean-out(G 2 , q), which 
demands that all outgoing edges from q in the updated 
graph are clean. This consistency check ensures that the pro¬ 
gram has not used the same name for two different thunks 
or references, e.g., by calling thunk)nmk, ei ] and later 
thunk(nm k, 62 ] in the same namespace cu. If this hap¬ 
pens, the graph will first map k@cu to e-\ but will later map 
it to 62 . Without this check, a computation q that depends on 
both 61 and 62 could be incorrect, because (re-)computing 
one of them might use cached values that were due to the 
other. Fortunately, this potential inconsistency is detected by 
all-clean-out: When a recomputation of q results in k@cu 
being mapped to a different value, all existing paths into 
k@cu are dirtied (by the last premise of Eval-thunkDirty 
above). Since q is one of the dependents, it will detect that 
fact and can signal an error. 

This fifth premise formalizes the double-use checking 
algorithm first described in Section |2.4| In particular, each 
use of Eval-computeDep corresponds to the implementation 
pushing (and later popping) a node from its force stack. By 
inspecting the outgoing edges upon each pop, it effectively 
verifies that each node popped from the stack is clean. 

Note that in the case q = po—where the “dependency” 
being computed is po itself—the last premise could be de¬ 
rived by Eval-forceClean, which looks up the result just com¬ 
puted by g; 6' 4 G 2 ;t'. 

Replacing Dirty Edges with Clean Edges. Eval-scrubEdge 
replaces a dirty edge (qi, a, dirty, q 2 ) with a clean edge 
(qi, a, clean, q 2 ]. First, it checks that all edges out from 
q 2 are clean; this means that the contents of q 2 are up-to- 



date. Next, it checks that the action a that represents qi’s 
dependency on q 2 is consistent with the contents of qi- For 
example, if q 2 points to a thunk with a cached result [ez^tx] 
and a = obs t, then the “consistent-action” premise checks 
that the currently cached result t 2 matches the result t that 
was previously used by q 1 . 

Creating Reference Nodes. Like Eval-refPlain, Eval-refDirty 
creates a node q with value v; Gi{qi— >v} = Gi- Unlike 
Eval-refPlain, Eval-refDirty does not check that q is not in 
the graph: if we are recomputing, q may already exist. So 
Gi{qi— >v} = G2 either creates q pointing to v, or updates q 
by replacing its value with v. It then marks the edges along 
all paths into q as dirty dirty-paths-in(G2, q] = G3; these 
are the paths from nodes that depend on q. 

Re-creating Clean References. Eval-refClean can be ap¬ 
plied only during recomputation, and only when G (q) = v. 
That is, we are evaluating ref(nmk,v] and allocating the 
same value as the previous run. Since the values are the 
same, we need not mark any dependency edges as dirty, but 
we do add an edge to remember that p depends on q. 

Creating Thunks. Eval-thunkDirty corresponds exactly to 
Eval-refDirty, but for thunks rather than values. 

Re-creating Thunks. Eval-thunkClean corresponds to Eval- 
refClean and does not change the contents of q. Note that 
the condition {exp(G, q]] = e applies whether or not q in¬ 
cludes a cached result. If a cached result is present, that is, 
G(q) = (e, t), it remains in the output graph. 

Reading References. Eval-getClean is the same as Eval- 
getPlain, except that it adds an edge representing the depen¬ 
dency created by reading the contents of q. 

The Rules vs. the Implementation. Our rules are not in¬ 
tended to be an “instruction manual” for building an imple¬ 
mentation; rather, they are intended to model our implemen¬ 
tation. To keep the rules simple, we underspecify two aspects 
of the implementation. 

First, when recomputing an allocation in the case when 
the allocated value is equal to the previously allocated value 
(G(q) = v), either Eval-refDirty or Eval-refClean applies. 
However, in this situation the implementation always fol¬ 
lows the behavior of Eval-refClean, since that is the choice 
that avoids unnecessarily marking edges as dirty and causing 
more recomputation. An analogous choice exists for Eval- 
thunkClean versus Eval-thunkDirty. 

Second, similarly to the original Adapton system, the 
timing of dirtying and cleaning is left open: Eval-scrubEdge 
can be applied to dirty edges with no particular connection to 
the po mentioned in the subject expression force (thkpo), 
and the timing of recomputation via Eval-computeDep is 
left open as well. Our implementations of dirtying and re- 
evaluation fix these open choices, and they are each analo¬ 
gous to the algorithms found in the original Adapton work. 


For details, we refer the interested reader to Algorithm 1 in 
[Hammer et al.| ( |^141 l. 

4.3 From-Scratch Consistency 

We show that an incremental computation modeled by our 
evaluation rules has a corresponding non-incremental com¬ 
putation: given an incremental evaluation of e that produced 
t, a corresponding non-incremental evaluation also produces 
t. Moreover, the values and expressions in the incremental 
output graph match those in the graph produced by the non- 
incremental evaluation. 

Eliding some details and generalizations, the from-scratch 
consistency result is: 

Theorem. fffncrementaJ derives Gi e JJ- G 2 ; t, then 
a non-incremental Vni derives [Gijp, hli, e JJ- [G 2 jp 2 ;t 
where [Gijp, C [G 2 JP 2 andP 2 = Pi U dom(W). 

Here, W is the set of pointers that T>i may allocate. 
The restriction function [G,J p, drops all edges from G, and 
keeps only nodes in the set P,. It also removes any cached 
results t. The set P, corresponds to the nodes in G, that 
are present at this point in the non-incremental derivation, 
which may differ from the incremental derivation since Eval- 
computeDep need not compute dependencies in left-to-right 
order. 

The full statement, along with dehnitions of W, the 
restriction function, and lemmas, is in the extended ver¬ 
sion ( [Hammer et al.|20T5| ) as Theorem [B.13[ 

5. Implementation 

We implemented NOMINAL Adapton as an OCaml library. 
In this section, we describe its programming interface, data 
structures, and algorithms. Additional details about memory 
management appear in Appendix[A| The code for Nominal 
Adapton is freely available: 

https://github.com/plum-umd/adapton.ocaml 

5.1 Programming Interface 

Figure]^ shows the basic NOMINAL Adapton API. Two of 
the data types, name and aref, correspond exactly to names 
and references in Sections and The other data types, 
mfn and athunk, work a little differently, due to limitations of 
OCaml: In OCamI, we cannot type a general-purpose memo 
table (containing thunks with non-uniform types), nor can 
we examine a thunk’s “arguments” (that is, the values of the 
variables in a closure’s environment)]^ 

To overcome these limitations, our implementation cre¬ 
ates a tight coupling between namespaces and memoized 
functions. The function mk_mfn k f takes a name k and a 
function f and returns a memoized function mfn. The func¬ 
tion f must have type ('arg.'res) mbody, i.e., it takes an mfn 


^ Recall from the start of the previous section that memoized calls are 
implemented as thunks in NOMINAL ADAPTON. 









type name 

val new : unit —> name 

val fork : name name * name 

type ('arg.'res) mfn 

type ('arg.'res) mbody = ('arg.'res) mfn —> 'arg —> 'res 
val mk_mfn : name ('arg.'res) mbody ^ ('arg.'res) mfn 
val call : ('arg.'res) mfn —> ('arg —r 'res) 

type 'res athunk 

val thunk : ('arg.'res) mfn —» name —> 'arg —> 'res athunk 
val force : 'res athunk —> 'res 

type 'a aref 

val aref : name 'a —!• 'a aref 

val get : 'a aref 'a 

val set : 'a aref —^ 'a —> unit 

Figure 7; Basic NOMINAL Adapton API 


and an 'arg as arguments, and produces a 'res. (The mfn is for 
recursive calls; see the example below.) 

Later on, we call thunk m k arg to create a thunk of type 
athunk from the memoized function m, with thunk name k 
(relative to m’s namespace) and argument arg. The code for 
the thunk will be whatever function m was created from. 
In other words, in our implementation, only function calls 
can be memoized (not arbitrary expressions), and each set of 
thunks that share the same function body also share the same 
namespace. 

Using this API, we can rewrite the map code from Sec¬ 
tion |23] as follows: 

let map f map_f_name = 
let mfn = mk_mfn map_f_name (fun mfn list -A 
match list with 
I Nil ^ Nil 

I Cons(hd. n. tLref) ^ 
let nl. n2 = fork n in 
let tl = get tLref in 

Cons(f hd, aref(nl. force(thunk mfn n2 tl))) ) 
in fun list call mfn list 

The code above differs from the earlier version in that 
the programmer uses mk_mfn with the name map_f_name to 
create a memo table in a fresh namespace. Moreover, memo- 
ization happens directly on the recursive call, by introducing 
a thunk (and immediately forcing it). 

5.2 Implementing Reuse 

Much of the implementation of NOMINAL Adapton re¬ 
mains unchanged from classic Adapton. Specifically, both 
systems use DCGs to represent dependency information 
among nodes representing thunks and refs, and both sys¬ 
tems traverse their DCGs to dirty dependencies and to later 
reuse (and repair) partially inconsistent graph components. 


These steps were described in Sections and and were 
detailed further by Hammer et al. ( 2014) l. 

The key differences between Nominal Adapton and 
Classic Adapton have to do with memo tables and thunks. 


Memo Tables and Thunks. Nominal Adapton memo 
tables are implemented as maps from names to DCG nodes, 
which contain the thunks they represent. When creating 
memo tables with mk_mfn, the programmer supplies a name 
and an mbody. Using the name, the library checks for an 
existing table (i.e., a namespace). If none exists, it creates an 
empty table, registers it globally, and returns it as an mfn. If 
a table exists, then the library checks that the given mbody 
is (physically) equal to the mbody component of the exist¬ 
ing mfn; it issues a run-time error if not. 

When the program invokes thunk, it provides an mfn, 
name, and argument. The library checks the mfn’s memo 
table for an existing node with the provided name. If none 
exists, it registers a fresh node with the given name in the 
memo table and adds an allocation edge to it from the current 
node (which is set whenever a thunk is forced). 

If a node with the same name already exists, the library 
checks whether the argument is equal to the current one. If 
equal, then the thunk previously associated with the name is 
the same as the new thunk, so the library reuses the node, 
returning it as an athunk and adding an allocation edge to 
the DCG. If not equal, then the name has been allocated 
for a different thunk either in a prior run, or in this run. 
The latter case is an error that we detect and signal. To 
distinguish these two cases, we use the check described in 
Section |2.4| Assuming no error, the library needs to reset 
the state associated with the name: It clears any prior cached 
result, dirties any incoming edges (transitively), mutates the 
argument stored in the node to be the new one, and adds an 
allocation edge. Later, when and if this thunk is forced, the 
system will run it. Further, because of the dirtying traversal, 
any nodes that (transitively or directly) forced this changed 
node are also candidates for reevaluation. 


Names. A name in NOMINAL Adapton is implemented 
as a kind of list, as follows: 


type name = Bullet j One of int * name | Two of int * name 

Ignoring the int part, this is a direct implementation of 
^NomA’s notion of names. The int part is a hash of the next 
element in the list (but not beyond it), to speed up disequality 
checks—if two One or Two elements do not share the same 
hash field they cannot be equal; if they do, we must compare 
their tails (because of hash collisions). Thus, at worst, estab¬ 
lishing equality is linear in the length of the name, but we 
can short circuit a full traversal in many cases. We note that 
in our applications, the size of names is either a constant, or 
it is proportional to the depth (not total size) of the DCG, 
which is usually sublinear (e.g., logarithmic) in the current 
input’s total size. 







6. Experimental Results 

This section evaluates NOMINAL Adapton’s performance 
against Adapton and from-scratch recomputation|^ We 
find that Nominal Adapton is nearly always faster than 
Adapton, which is sometimes orders of magnitude slower 
than from-scratch computation. NOMINAL Adapton al¬ 
ways enjoys speedups, and sometimes very dramatic ones 
(up to 10900x). 


6.1 Experimental Setup 

Our experiments measure the time taken to recompute the 
output of a program after a change to the input, for a va¬ 
riety of different sorts of changes. We compare NOMINAL 
Adapton against classic Adapton and from-scratch com¬ 
putation on the changed input; the latter avoids all IC-related 
overhead and therefore represents the best from-scratch time 
possible. 

We evaluate two kinds of subject programs. The first set 


is drawn from the IC literature on SAC and Adapton (Ham- 


|mer et aL]|201 1| |2009| |2014[ ). These consist of standard list 
processing programs; (eager and lazy) filter, (eager and lazy) 
map, reduce(min), reduce(sum), reverse, median, and a list- 
based mergesort algorithm. Each program operates over ran¬ 
domly generated lists. These aim to represent key primitives 
that are likely to arise in standard functional programs, and 
use the patterns discussed in S ection |3.1| We also consider 
an implementation of quickhull (Barber et al. 1996 1 , a divide- 
and-conquer method for computing the convex hull of a set 
of points in a plane. Convex hull has a number of applica¬ 
tions including pattern recognition, abstract interpretation, 
computational geometry, and statistics. 

We also evaluate an incremental IMP interpreter, as dis¬ 
cussed in Section 3.3 measuring its performance on a va¬ 
riety of different IMP programs, fact iteratively computes 
the factorial of an integer. intlog;fact evaluates the sequence 
of computing an integer logarithm followed by factorial, 
array max allocates, initializes, and destructively computes 
the maximum value in an array, matrix mult allocates, ini¬ 
tializes, and multiplies two square matrices (implemented as 
arrays of arrays of integers). These IMP programs exhibit 
imperative behavior not otherwise incrementalizable, except 
as programs evaluated by a purely functional, big-step inter¬ 
preter implemented in an incremental meta-language. 

All programs were compiled using OCaml 4.01.0 and run 
on an 8-core, 2.26 GHz Intel Mac Pro with 16 GB of RAM 
running Mac OS X 10.6.8. 


6.2 List-Based Experiments 

Table contains the results of our list experiments. For 
each program (leftmost column), we consider a randomly 

report that for interactive, lazy usage patterns, 
outperforms another state-of-the-art incremental 
technique, self-adjusting computation (SAC), which sometimes can incur 
significant slowdowns. We do not compare directly against SAC here. 


® Hammer et al. 


2014 


Adapton substantially 


Batch-mode comparison (“demand all”) 


Program 

n 

Edit 

FS (ms) 

A(x) 

NA (X) 

eager filter 

le4 

insert 

21 

0.178 

1.29 



delete 

21 

0.257 

1.39 



replace 

21 

0.108 

1.27 

eager map 

le4 

insert 

21.6 

0.0803 

1.02 



delete 

21.6 

0.0920 

1.01 



replace 

21.6 

0.0841 

1.09 

min 

le5 

insert 

424 

2790 

2980 



delete 

424 

4450 

4720 



replace 

424 

1850 

2310 

sum 

le5 

insert 

421 

785 

833 



delete 

421 

1140 

1230 



replace 

421 

727 

733 

reverse 

le5 

insert 

197 

0.0404 

1.23 



delete 

197 

0.764 

1.19 



replace 

197 

0.0404 

1.23 

median 

le4 

insert 

3010 

0.747 

127 



delete 

3010 

192 

115 



replace 

3010 

0.755 

148 

mergesort 

le4 

insert 

267 

0.212 

12.0 



delete 

267 

11.0 

10.1 



replace 

267 

0.205 

10.5 

quickhull 

le4 

insert 

853 

0.0256* 

3.78 



delete 

853 

0.0270* 

4.11 



replace 

853 

0.0378* 

3.86 


(a) Speedups of batch-mode experiments 


Demand-driven comparison {“demand one”) 

Program 

n 

Edit 

FS (ms) 

A(x) 

NA(x) 

lazy filter 

le5 

insert 

0.016 

3.79 

3.55 



delete 

0.016 

18.1 

16.3 



replace 

0.016 

3.55 

3.20 

lazy map 

le5 

insert 

0.016 

4.08 

3.79 



delete 

0.016 

18.1 

20.4 



replace 

0.016 

3.71 

3.62 

reverse 

le5 

insert 

188 

0.067 

2130 



delete 

188 

50.8 

4540 



replace 

188 

0.068 

2360 

mergesort 

le4 

insert 

63.4 

96.3 

369 



delete 

63.4 

111 

752 



replace 

63.4 

86.2 

336 

quickhull 

le4 

insert 

509 

0.0628* 

5.30 



delete 

509 

0.0571* 

5.52 



replace 

509 

0.0856* 

5.23 


(b) Speedups of demand-driven experiments 
Table 1: List benchmarks 


generated input of size n and three kinds of edits to it: insert, 
delete, and replace. For the first, we insert an element in the 
list; for the second, we delete the inserted element; for the 
last, we delete an element and then re-insert an element with 
a new value. Rather than consider only one edit position, we 
consider ten positions in the input list, spaced evenly (1/10 
through the list, 2/10 through the list, etc.), and perform the 
edit at those positions, computing the average time across 
all ten edits. We report the median of seven trials of this 
experiment. 

The table reports the time to perform recomputation from 
scratch, in milliseconds, in column FS, and then the speed¬ 
up (or slow-down) factor compared to the from-scratch time 











































for both Adapton, in column A, and NOMINAL Adapton, 
in column NA. Table [Ti] considers the case when all of the 


program’s output is demanded, whereas Table lb considers 
the case when only one element of the output is demanded, 
thus measuring the benehts of both nominal and classic 
Adapton in a lazy setting. Note that in the lazy setting, 
FS sometimes also avoids complete recomputation, since 
thunks that are created but never forced are not executed. 


Results: Demand All. Table [Ta] focuses on benchmarks 
where all of the output is demanded, or when there is only 
a single output value (sum and minimum). In these cases, 
several patterns emerge in the results. 

First, for eager map (Section]^ and eager hlter, NOM¬ 
INAL Adapton gets modest speedup and breaks even, re¬ 
spectively, while Adapton gets slowdowns of one to two 
orders of magnitude. As Section explains, Adapton re¬ 
computes and reallocates a linear number of output elements 
for each 0(1) input change (insertion, deletion or replace¬ 
ment). By contrast, NOMINAL Adapton need not rebuild 
the prehx of the output lists. 

Next, the benchmarks minimum and sum use the proba¬ 
bilistically balanced trees from Section o to do an incre¬ 
mental fold where, in expectation, only a logarithmic num¬ 
ber of intermediate computations are affected by a small 
change. Due to this construction, both Adapton and Nom¬ 
inal Adapton get large speedups over from-scratch com¬ 
putation (up to 4720x). Nominal Adapton tends to get 
slightly more speedup, since its use of names leads to less 
tree rebuilding. This is similar to, but not as asymptotically 
deep as, the eager map example (O (log n) here versus O (n) 
above). 

The next four benchmarks (reverse, mergesort, median, 
quickhull) show marked contrasts between the times for 
Nominal Adapton and Adapton; In all cases. Nomi¬ 
nal Adapton gets a speedup (from about 4x to 148 x), 
whereas Adapton nearly always gets a slowdown. Two ex¬ 
ceptions are the deletion changes that revert a prior insertion. 
In these cases, Adapton reuses the original cache informa¬ 
tion that it duplicates (at great expense) after the insertion. 
Adapton gets no speedup for quickhull, our most complex 
benchmark in this table. By contrast, NOMINAL Adapton 
performs updates orders of magnitude faster than Adapton 
and gets a speedup over from-scratch; the stars (*) indicate 
that we ran quickhull at one tenth of the listed input size for 
Adapton, because otherwise it used too much memory due 
to having large memo tables but little reuse from them. 

Results: Demand One. Table [T^ focuses on benchmarks 
where one (of many possible) outputs are demanded. In these 
cases, two patterns emerge. First, on simple lazy list bench¬ 
marks map and hlter, Adapton and Nominal Adapton 
perform roughly the same, with Adapton getting slightly 
higher speedups than NOMINAL Adapton. These cases are 
good hts for Adapton’s model, and names only add over¬ 
head. 


Batch-mode comparison {“demand all”) 


Program 

n 

Edit 

FS (ms) 

A(x) 

NA(x) 

fact 

5e3 

repl 

945 

0.520 

10900 



swapl 

947 

2410 

4740 



swap2 

955 

4740 

6590 



ext 

847 

0.464 

0.926 

intlog;fact 

5e3 

swap 

849 

0.413 

3.18 

array 

21 u 

repll 

I9I 

0.323 

6.52 

max 


repl2 

I9I 

0.310 

7.62 

matrix 

20x20 

swapl 

4500 

0.617 

1.31 

mult 


swap2 

4500 

0.756 

1.17 


25x25 

ext 

6100 

1.50 

1.55 


Table 2: Speedups of IMP interpreter experiments 


Second, on more involved list benchmarks (reverse, 
mergesort and quickhull), NOMINAL Adapton delivers 
greater speedups (from 5x to 4540 x) than Adapton, 
which often delivers slowdowns. Two exceptions are merge¬ 
sort, where Adapton delivers speedups, but is still up to 
6.7X slower than Nominal Adapton, and the deletion 
changes, which—as in the table above—are fast because of 
spurious duplication in the insertion change. 

In summary. Nominal Adapton consistently delivers 
speedups for small changes, while Adapton does so to a 
lesser extent, and much less reliably. 

6.3 Interpreter Experiments 

We tested the incremental behavior of the IMP interpreter 
with three basic forms of edits to the input programs: replac¬ 
ing values (replace), swapping subexpressions (swap), and 
increasing the size of the input (ext). These experiments all 
take the following form; evaluate an expression, mutate the 
expression, and then reevaluate. 

• For fact, repl mutates the value of an unused variable; 
swapl reverses the order of two assignments at the start 
of the program; swap2 reverses the order of two assign¬ 
ments at the end; and ext increases the size of the input. 

• For intlog;fact, swap swaps the two subprograms. 

• For array max, repll replaces a value at the start of the 
array, and repl2 moves a value from the start to the end 
of the array. 

• For matrix mult, swapl reverses the order of the initial 
assignments of the outer arrays of the input matrices; 
swap2 reverses the order of the while loops that initialize 
the inner arrays of the input matrices; and ext extends the 
dimensions of the input arrays. 

Results. Table summarizes the results, presented the 
same way as the list benchmarks. We can see that NOMINAL 
Adapton provides a speedup over from-scratch computa¬ 
tion in all but one case, and can provide dramatic speedups. 
In addition, NOMINAL Adapton consistently outperforms 
classic Adapton, in some cases providing a speedup where 
Adapton incurs a (sizeable) slowdown. 
















The fact program’s repl experiment shows significant per¬ 
formance improvement due to names. Classic Adapton 
dirties each intermediary environment and is forced to re¬ 


compute. With the naming strategy outlined in Section 3.3 


the environment is identified without regard to the particu¬ 
lar values inserted. Future computations that depend on the 
environment, but not the changed value in particular, are 
reused. The fact swap experiments show significant speedup 
for both classic Adapton and Nominal Adapton, be¬ 
cause the trie map representation remains unchanged regard¬ 
less of order of the assignments. 

The remaining results fall into two categories. The ed¬ 
its made to intlog;fact, array max, and matrix mult’s swaps 
show speedups between 1.17x and 7.62x with NOMINAL 
Adapton, while classic Adapton exhibits a slowdown, 
due to spending much of its time creating and evaluating 
new nodes in the DCG. Nominal Adapton, on the other 
hand, spends its time walking the already-present nodes and 
reusing many (from 25% to as much as 99%) of them, with 
the added benefit of far better memory performance. 

The last category includes the ext tests for fact (increasing 
the input value) and matrix mult (extending the dimensions 
of the input matrices). Such changes have pervasive effects 
on the rest of the computation and are a challenge to in¬ 
cremental reuse. Extension for matrix multiplication shows 
a modest speedup over the from-scratch running time for 
both nominal and classic Adapton. Nominal Adapton 
is able to reuse a third of the nodes created during the orig¬ 
inal run, while classic Adapton is not able to reuse any. 
Increasing the value of the input to factorial causes similar 
behavior, though the single, short loop prevents the amount 
of reuse from overcoming the from-scratch time. 


7. Related Work 

Here we survey past approaches to incremental computation, 
organizing our discussion into three categories: static ap¬ 
proaches, dynamic approaches, and specialized approaches. 

Static Approaches to IC. These approaches transform pro¬ 
grams to derive a second program that can process “deltas”; 
the derived program takes as input the last (full) output and 
the representation of an input change, and produces (the rep¬ 
resentation of) the next output change. This program deriva¬ 
tion is performed a priori, before any dynamic changes are 
issued. As such, static approaches have the advantage of not 
incurring dynamic space or time overhead, but also carry 
disadvantages that stem from not being dynamic in nature: 
They cannot handle programs with general recursion, and 
cannot take advantage of cached intermediate results, since 
by design, there are none 
elbaum|[l995| l. Other static 
into ones that cache and reuse past results, given a predefined 
class of input changes dLiu etal.|1998l l. Future work should 
explore an empirical comparison between these approaches 
and comtemporary dynamic approaches, described below. 


( Cai et ar| 2014 Liu and Teit- 


approaches transform programs 


Dynamic Approaches to IC. In contrast to static ap¬ 
proaches, dynamic approaches attempt to trade space for 
time savings. A variety of dynamic approaches to IC have 
been proposed. Most early approaches fall into one of two 
camps: they either perform function caching of pure pro¬ 
grams ( |Bellman|1957| |McCarthy|19^ |Michie|1968t [Pugh| 
|1988| l, or they support input mutation and employ some 
form of dynamic dependency graphs. However, the pro¬ 
gramming model advanced by earlier work on dependence 
graphs lacked features like general recursion and dynamic 
allocation, instead restricting programs to those expressible 
as attribute grammars (a language of declarative constraints 
over tree structures) (|Demers et al.|1981[|Reps|1982a|b||Vogt 
|etal.|1991» . 

Some recent general-purpose approaches to dynamic IC 
(SAC and Adapton) support general-purpose input struc¬ 
tures and general recursion; internally, they use a notion of 
memoization to find and reuse portions of existing depen¬ 


dency graphs. As described in Hammer et al. (20141, SAC 


and Adapton differ greatly in the programming model they 
support (SAC is eager/batch-oriented whereas Adapton 
is demand-driven) and in how they represent dependency 
graphs. Consequently, they have different performance char¬ 
acteristics, with Adapton excelling at demand-driven and 
interactive settings, and SAC doing better in non-interactive, 
batch-oriented settings ( [Hammer et al.pOf^ . 

The presence of dynamic memory allocation in SAC 
poses a reuse problem due to “fresh” object identities, and 
thus benefits from a mechanism to deterministically match 
up identities from prior runs. Various past work on SAC 


addresses this problem in some form (Acar and Ley-Wild 


|2009[|Acar et al.|2004| [20061 [Hammer and Acar|2008] l de- 

scribing how to use “hints” or “keys.” The reuse problem 
in Nominal Adapton is more general in nature than in 
SAC, and thus requires a very different solution. For exam¬ 
ple, Nominal Adapton’s DCG and more general memo 
tables do not impose SAC’s total ordering of events, admit¬ 
ting more opportunities for reuse, but complicating the issue 
of assuring that names are not used more than once within a 
run. The use of thunks, which also need names, adds a fur¬ 
ther layer of complication. This paper addresses name reuse 
in this (more general) IC setting. Further, we address other 
naming issues, such as how to generate new names from 
existing ones (via fork) and how to determinize memo table 
creation (via named namespaces). 

Ongoing research in programming languages and sys¬ 


tems continues to generalize memoization. Bhatotia et al. 


(2015 I extend memoization to parallel C and C-H- programs 
written against a traditional UNIX threading API. [Bhato-[ 
[tia et al.| ( [2011[ ) extend memoization to distributed, cloud- 
based settings (MapReduce-style computations in particu¬ 
lar). Chen et al. ( 2014| l reduce the (often large) time and 
space overhead, which is pervasive in both SAC and in 
Adapton. In particular, they propose coarsening the granu- 
















































larity of dependence tracking, and report massive reductions 
(orders of magnitude) in space as a result. We believe that 
their approach (“probabilistic chunking”) should be imme¬ 
diately applicable to our setting, as well as to classic Adap- 
TON. Indeed, early results for mergesort indicate up to an 
order-of-magnitude reduction in overhead. 


Specialized Approaches to IC. Some recent approaches 
to IC are not general-purpose, but exploit domain-specihc 
structure to handle input changes efficiently. DITTO incre¬ 
mentally checks invariants in Java programs, but is limited to 
invariant checking ( Shankar and Bodi^|2007 1. iSQL incre¬ 
mentally repairs database views (queries) when the under¬ 
lying data changes due to insertions and removals of table 
rows ( [Mitschke et al.|20T4l l. 

Finally, reactive programming (especially functional re¬ 
active programming or FRP) shares some elements with in¬ 
cremental computation: both paradigms offer programming 
models for systems that strive to efficiently react to “outside 
changes”; internally, they use graph representations to model 


dependencies in a program that change over time (Cooper 


and Krishnamurthi 200ffi Czaplicki and Chong 2013 Kr- 


ishnaswami and Benton |201 1| |. However, the chief aim of 
FRP is to provide a declarative means of specifying pro¬ 
grams whose values are time-dependent (stored in signals), 
whereas the chief aim of IC is to provide time savings for 
small input changes (stored in special references). The dif¬ 
ferent scope and programming model of FRP makes it hard 
to imagine using it to write an efficient incremental sorting 
algorithm, though it may be possible. On the other hand, IC 
would seem to be an appropriate mechanism for implement¬ 
ing an FRP engine, though the exact nature of this connec¬ 
tion remains unclear. 


8. Conclusion 

This paper has presented nominal matching, a new strat¬ 
egy that general-purpose incremental computation can use 
to match a proposed computation against a prior, memoized 
one. With nominal matching, programmers may explicitly 
associate a name with a memoized computation, and match¬ 
ing is done by name equality. Nominal matching overcomes 
the conservativity of structural matching, the most com¬ 
monly employed approach, which compares computations 
based on their structure and thus may fail to reuse prior 
results when it should (i.e., those that are not structurally 
identical but require little work to bring up-to-date). We have 
implemented nominal matching as part of NOMINAL Adap- 
TON, an extension to the Adapton general-purpose system 
for incremental computation, and endowed it with names¬ 
paces for more flexible management of names in practical 
programs. We have formalized Nominal Adapton’s (and 
Adapton’s) algorithms and proved them correct. We have 
implemented a variety of data structures and benchmark 
programs in Nominal Adapton. Performance experi¬ 
ments show that compared to Adapton (which employs 


structural matching) NOMINAL Adapton enjoys uniformly 
better performance, sometimes achieving many orders-of- 
magnitude speedups over from-scratch computation when 
Adapton would suffer significant slowdowns. 
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Supplement to “Incremental Computation with Names” 

This supplementary material contains additional details about how NOMINAL Adapton manages space, in Appendix [A| Our 
full from-scratch consistency result, along with the definitions and lemmas it uses, appears in Appendix [B] 

A. Space management 

In a long-running program, memo tables could grow without bound. NOMINAL Adapton helps reduce table sizes, as we have 
already seen, but we still need a mechanism to clean out the tables when space becomes limited. A natural idea is to implement 
a memo table’s mapping from name to DCG node with a weak reference, so that if the table is the only reference to the node, 
the node can be garbage collected when the system is short on space. This is not quite enough, though, because to implement 
dirtying, DCG edges are bidirectional. To avoid space leaks, it is critical to also make these backedges weak. 

Unfortunately, using weak references for both memo tables and back edges (as implemented in the original Adapton) is 
generally unsound. Adapton supports an interactive pattern called swapping, wherein DCG components can be swapped in 
and out of the active DCG. Pathologically, during the time that a sub-computation is swapped out, the garbage collector could 
remove some of this DCG structure, but not all of it. In particular, it could null out some of its weak back edges, because these 
nodes are only reachable by weak references. But if this swapped out sub-computation is later swapped back into the DCG, 
these (weak) back edges will be gone, and we will potentially fail to dirty nodes that ought to be dirty, as future changes occur. 

To fix the GC problem, we still use weak references for back edges, but use strong references for memo table entries, so that 
from the GC’s point of view, all DCG nodes are always reachable. To implement safe space reclamation, we also implement 
reference counting of DCG nodes, where the counts reflect the number of strong edges reaching a node. When DCG edges 
are deleted, the reference counts of target nodes are decremented. Nodes that reach zero are not immediately collected; this 
allows thunks to be “resurrected” by the swapping pattern. Instead, we provide a flush operation for memo tables that deletes 
the strong mapping edge for all nodes with a count of zero, which means they are no longer reachable by the main program. 
Deletion is transitive: removing the node decrements the counts of nodes it points to, which may cause them to be deleted. 

An interesting question is how to decide when to invoke flush; this is the system’s eviction policy. One obvious choice is to 
flush when the system starts to run short of memory (based on a signal from the GC), which matches the intended effect of the 
unsound weak reference-based approach. But placing the eviction policy under the program’s control opens other possibilities, 
e.g., the programmer could invoke flush when it is semantically clear that thunks cannot be restored. We leave to future work a 
further exploration of sensible eviction policies. 

B. Metatheory of AiMomA 

B.l Overview 

Our main formal result in this paper, from-scratch consistency, states that given an evaluation derivation corresponding to 
an incremental computation, we can construct a derivation corresponding to a non-incremental computation that returns the 
same result and a corresponding graph. That is, the incremental computation is consistent with a computation in the simpler 
non-incremental system. 

To properly state the consistency result, we need to define what it means for a graph to be well-formed (Section [B.2| i, relate 
the incremental computation’s DCG to the non-incremental computation’s store (Section [B.3| l, describe the sets of nodes read 
and written by an evaluation derivation (Section [B.4| i, and prove a store weakening lemma (Section [B.6| l. The consistency result 
itself is stated and proved in Section [BT7| 

B.2 Graph Well-Formedness 

The judgment G h H wf is read “H is a well-formed subset of G”. It implies that H is a linearization of a subset of G: within 
H, information sources appear to the left of information sinks, dependency edges point to the left, and information flows to the 
right. Consequently, H is a dag. 

For brevity, we write G wf for G h G wf, threading the entire graph G through the rules deriving G h H wf. The well- 
formedness rules in Figure [^decompose the right-hand graph, and work as follows: 

• For values (Grwf-val) and thunks with no cached result (Grwf-thunk), the rules only check the correspondence between G 
(the entire graph) and H (the subgraph). 

• For thunks with a cached result, Grwf-thunkCache examines the outgoing edges. If they are all clean, then it checks that 
evaluating e again would not change the graph at all: T) :: G h]l, e JJ- G;t. If one or more edges are dirty, it checks that all 
incoming edges are dirty. 


G h H wf 


- Grwf-emp 

G h £ wf 


G h H wf G(p] = V 
G h H,p:v wf 


Grwf-val 


GhHwf G(p)=e 
G h H,p:e wf 


Grwf-thunk 


G h H wf 


G(p] = (e,t) 

if all-clean-out(G,p] then (I? :: G e 4 G;t] 
if not all-clean-out(G,p) then all-dirty-in(G, p] 

G h H,p:(e,t] wf 


Grwf-thunkCache 


G h H wf 


(p, a, dirty, q) G G 
q G dom(H) 

if (po, ao,bo,p) G G then bo = dirty 
G h H, (p, Q, dirty, q] wf 


Grwf-dirtyEdge 


(p, a, clean, q) G G 
consistent-action(H, a, q) 
GhHwf all-clean-out(G, q) 

G h H, (p, a, clean, q] wf 


Grwf-cleanEdge 


Figure 8: Graph well-formedness rules 


• Grwf-dirtyEdge checks that all edges flowing into a dirty edge are dirty; given edges from p to q and from q to r, where 
the edge from q to r is dirty (meaning that q depends on r and r needs to be recomputed), the edge from p to q should also 
be dirty. Otherwise, we would think we could reuse the result in p, even though p (transitively) depends on r. 

Conversely, if an edge from p to q is clean (Grwf-cleanEdge), then all edges out from q must be clean (otherwise we would 
contradict the “transitive dirtiness” just described). Moreover, the action a stored in the edge from p to q must be consistent 
with the contents of q. 


B.3 From Graphs to Stores: the Restriction Function 

To relate the graph associated with an incremental evaluation to the store associated with a non-incremental evaluation, we 
define a function [GJ p that restricts G to a set of pointers P, drops cached thunk results (*), and erases all edges (**): 


Definition B.l (Restriction). 


[ejp = £ 

[G,p:vjp = [GJp,p:v ifpGP 

[G,p:vjp = [gJp ifp ^ P 

[G,p:ejp = [GJp,p:e ifp G P 

[G,p:ejp = [GJp ifp ^ P 

(*) LG,p:(e,t)Jp = [GJp,p:e ifpGP 
[G,p:(e,t)Jp = [gJp ifp ^ P 

(**) LG,(p,a,b, q)Jp = [GJp 


B.4 Read and Write Sets 

Join and Merge Operations. To specify the read and write sets, we use a separating join Hi * H 2 on graphs; Hi * H 2 = 
(Hi, H 2 ) if dom(Hi) _L dom(H 2 ), and undefined otherwise. 

We also define a merge Hi U H 2 that is defined for subgraphs with overlapping domains, provided Hi and H 2 are consistent 
with each other. That is, if p G dom(Hi) and p G dom(H 2 ), then Hi (p) = H 2 {p]. 

Definition B.2 (Reads/writes). The effect of an evaluation derived by T), written V reads R writes W, is defined in Figure]^ 










V by Eval-fix(I?o] reads R writes W 

V by Eval-case(I?o] reads R writes W 

V by Eval-split(I?o] reads R writes W 
T) by Eval-namespace(I?o] reads R writes W 

T) by Eval-fork() reads e writes e 

V by Eval-refDirtyO reads £ writes q:v 

V by Eval-refClean() reads £ writes q:v 
V by Eval-thunkDirty() reads £ writes q;eo 

V by Eval-thunkClean(] reads £ writes q:G(q) 
T) by Eval-getClean() reads q:v writes £ 
V by Eval-forceClean() reads R',q;(e, t) writes W' 


if reads Ri writes W] 

and I?2 reads R2 writes W2 

if reads Ri writes W] 

and I?2 reads R2 writes W2 

if reads Ri writes Wj 

and I?2 reads R2 writes W2 

if reads Ri writes Wj 

and I?2 reads R2 writes W2 
and dom(Wi) C dom(W2) 

Vq reads R writes W 
Vo reads R writes W 
Vq reads R writes W 
Vo reads R writes W 

where e = ref(nmk,v) and q = k@cu 
where e = ref(nmk,v) and q = k@cu 
where e = thunk(nm k, eo) 
where e = thunk (nm k, eo) 

where e = get(refq) and q = k@tu and G(q)=v 

where e = force (thk q ) 

and V reads R' writes W' 

where V is the derivation that computed t (see text) 

if Vo reads R writes W 


V by Eval-scrubEdge(I?o) reads R writes W 

Figure 9: Read- and write-sets of a derivation 


V by Eval-term() reads £ writes £ 

V by Eval-app(I?i, I?2) reads Ri U (R2 — Wi ) writes Wi * W2 

V by Eval-bind(I?i, I?2) reads Ri U (R2“Wi) writes Wi * W2 

V by Eval-nest(I?i, I?2) reads Ri U (R2 — Wi ) writes Wi * W2 

V by Eval-computeDep(I?i, I?2) reads Ri U R2 writes W2 

if 
if 
if 
if 


This is a function over derivations. We write “V by TZ[V] reads R writes W” to mean that rule TZ concludes V and has 
subderivations V. For example, V by Eval-fix(I?o) reads R writes W provided that Vq reads R writes W where Vo derives 
the only premise of Eval-fix. 

In the Eval-forceClean case, we refer back to the derivation that (most recently) computed the thunk being forced (that is, 
the first subderivation of Eval-computeDep). A completely formal definition would take as input a mapping from pointers q to 
sets R' and W', return this mapping as output, and modify the mapping in the Eval-computeDep case. 


Agreement. We want to express a result (Lemma [B.5| ( |Respect for write-set 1 ) that evaluation only affects pointers in the write 
set W, leaving the contents of other pointers alone, so we define what it means to leave pointers alone; 


Definition B.3 (Agreement on a pointer). Graphs G] and G 2 agree on p iff either exp{Gi ,p) = exp(G 2 ,p), orp:v G G] and 
p:v G G 2 . 


Definition B.4 (Agreement on a set of pointers). Graphs Gi and G 2 agree on a set P of pointers iff Gi and G 2 agree on each 
p G P. 


Lemma B.5 (Respect for write-set). 

IfV :: G FDj e 4J- G t where V is incremental and V reads R writes W 
then G' agrees with G on dom(G) — dom(W). 


Proof. By a straightforward induction on V, referring to Definition |B.2| 

In the Eval-forceClean case, use the fact that G' differs from G only in the addition of an edge, which does not affect 
agreement. □ 





B.5 Satisfactory derivations 


In our main result (Theorem B.13 i, we will assume that all input and output graphs appearing within a derivation are well- 
formed, and that the read- and write-sets are defined; 


Definition B.6 (Locally satisfactory). 

A derivation I? :: G i hj^ e JJ, Gi; t is locally satisfactory if and only if 


(1) G] wf and Gz wf 

(2) V reads R writes W is defined 


Definition B.7 (Globally satisfactory). 

An evaluation derivation V :: Hi hH, e JJ, H 2 ; t is globally satisfactory, written V satisfactory, if and only if V is locally 
satisfactory and all its subderivations are locally satisfactory. 


B.6 Weakening 

The main result needs to construct a non-incremental derivation in a different order from the given incremental derivation. In 
particular, the hrst evaluation I?i done in Eval-computeDep will be done “later” in the non-incremental derivation. Since it is 
done later, the graph may have new material G', and we need a weakening lemma to move from a non-incremental evaluation 
of I?i (obtained through the induction hypothesis) to a non-incremental evaluation over the larger graph. 

Lemma B.8 (Weakening (non-incremental)). 

IfT) :: Gi e JJ- GiH and V is non-incremental 
and G' is disjoint from G 1 and Gz 

then P' :: Gi, G' e JJ. Gi, G';t whereV is non-incremental. 

Proof By induction on T). 

• Cases Eval-term, Eval-app, Eval-fix, Eval-bind, Eval-case, Eval-split, Eval-fork, Eval-namespace, Eval-nest; 

These rules do not manipulate the graph, so just use the i.h. on each subderivation, then apply the same rule. 

• Case Eval-refPlain; Since Gi{qi—>v}= G 2 , we have q € dom(G 2 ). 

It is given that dom(G') _L dom(G 2 ]. Therefore q ^ dom(Gi, G'). 

By definition, (Gi, GOlqi— >v} = (G 2 , G']. 

Apply Eval-refPlain. 

• Case Eval-thunkPlain: Similar to the Eval-refPlain case. 

• Case Eval-forcePlain: We have exp(Gi, q] = eo. Therefore exp(Gi, G', q) = Zq. Use the i.h. and apply Eval-forcePlain. 

• Case Eval-getPlain: Similar to the Eval-forcePlain case. □ 


B.7 Main result: From-scratch consistency 


At the highest level, the main result (Theorem B. 13 1 says: 


First approximation 

If H] e 4), H 2 ; t by an incremental derivation, 

then Hj I-J4, e JJ, t, where Hj is a non-incremental version of Hj and H 2 is a non-incremental version of H 2 . 


Using the restriction function from Section B.3 we can refine this statement; 


Second approximation 

If Hi hH, e 4), H 2 ; t by an incremental derivation and Pi C dom(Hi), 

then [Hi J p, hH, e jj- [H 2 J P 2 ; t by a non-incremental derivation, for some P 2 such that Pi C P 2 . 


Here, the pointer set Pi gives the scope of the non-incremental input graph [Hijp,, and we construct P 2 describing the 
non-incremental output graph [H 2 J p^ ■ 

We further refine this statement by involving the derivation’s read- and write-sets; the read set R must be contained in Pi, 
the write set W must be disjoint from Pi (written dom(W) _L Pi), and P2 must be exactly Pi plus W. In the non-incremental 
semantics, the store should grow monotonically, so we will also show [Hi J p, C LH 2 JP 2 : 


Third approximation 

If Hi hli, e 41 H 2 ; t by an incremental derivation T> with T) reads R writes W, 
and Pi C dom(Hi) such that dom(R) C Pi and dom(W) _L Pi 





then [Hijp, hlL e JJ, L^ijpa'.t 

where [HiJp, C [H 2 JP 2 and P 2 = Pi U dom(W). 


Even this rehnement is not quite enough, because the incremental system can perform computations in a different order than 
the non-incremental system. Specihcally, the Eval-computeDep rule carries out a subcomputation hrst, then continues with a 
larger computation that depends on the subcomputation. The subcomputation does not fit into the non-incremental derivation 
at that point; non-incrementally, the subcomputation is performed when it is demanded by the larger computation. Thus, we 
can’t just apply the induction hypothesis on the subcomputation. 

However, the subcomputation is “saved” in its (incremental) output graph. So we incorporate an invariant that all thunks 
with cached results in the graph “are consistent”, that is, they satisfy a property similar to the overall consistency result. When 
this is the case, we say that the graph is from-scratch consistent. The main result, then, will assume that the input graph is from- 
scratch consistent, and show that the output graph remains from-scratch consistent. Since the graph can grow in the interval 
between the subcomputation of Eval-computeDep and the point where the subcomputation is demanded, we require that the 
output graph G 2 of the saved derivation does not contradict the larger, newer graph H. This is part (4) in the next definition. 
(We number the parts from (i) to (ii) and then from (1) so that they mostly match similar parts in the main result.) 


Definition B.9 (Erom-scratch consistency of a derivation). 

A derivation :: Gi hfj, e 4J- G 2 ;t is 

from-scratch consistent for Pq C dom(Gi ) up to W if and only if 

(i) Vi satisfactory where D, reads R writes W 

(ii) dom(R] C Pq and dom(W) _L Pq 

(1) there exists a non-incremental derivation V^i :: [Gijp, hL e4 

(2) [Gijpq C [G2JP2 

(3) P2 = Pq U dom(W) 

(4) LG 2 JP 2 ^ L*4Jdom(H) 


Definition B.IO (Erom-scratch consistency of graphs). 

A graph H is from-scratch consistent 

if, for all q G dom{H) such that H(q] = (e, t), 

there exists V^ :: Gi hH, e 4J- G 2 ;t 

and Pq C dom(Gi ] 

such that Dq is from-scratch consistent (Dehnition|B.9| for Pq up to H. 


The proof of the main result must maintain that the graph is from-scratch consistent as the graph becomes larger, for which 
Lemma B.12 (Consistent graph extension 1 is useful. 


Lemma B.ll (Consistent extension). 

IfVq is from-scratch consistent for Pq up to H 
and H C H' 

then Vq is from-scratch consistent for Pq up to H'. 


Proof Only part (4) of Dehnition B.9 involves the 

(l)-( 3 ). 


‘up to” part of from-scratch consistency, so we already have (i)-(iii) and 


We have (4) LG 2 JP 2 ^ Using our assumptions, LHJdom(H) ^ LH'Jdom(H')- 

Therefore (4) LG 2 JP 2 C LH'Jdom(H')- GI 


Lemma B.12 (Consistent graph extension), 
ff H is from-scratch consistent 
and HC H' 

and, for all q G dom(H') — dom(H) such that H'(q] = (e, t), 
there exists Vq :: Gi e JJ- G 2 ; tandPq C dom(Gi] 
such thatVq is from-scratch consistent (Definition |J3.9| ) 
for Pq up to H', 

then H' is from-scratch consistent. 


Proof. Use Lemma B.ll (Consistent extension 1 on each “old” pointer with a cached result in H, then apply the definitions for 
each “new” pointer with a cached result in dom(H') — dom(H). □ 









At last, we can state and prove the main result, which corresponds to the “third approximation” above, plus the invariant 
that the graph is from-scratch consistent (parts (iii) and (4)). 

We present most of the proof in a line-by-line style, with the judgment or proposition being derived in the left column, and 
its justification in the right column. In each case, we need to show four different things (l)-(4), some of which are obtained 
midway through the case, so we highlight these with “(1) «*■ ”, and so on. 

Theorem B.13 (From-scratch consistency). 

Given an incremental Vi :: Hi e jj- HaH where 

(i) Vi satisfactory where V reads R writes W 

(ii) a set of pointers Pi C dom(Hi ] is such that dom{R) C Pi and dom{W) _L Pi 
(Hi) Hi is from-scratch consistent (Definition \B. 1 OP 

then 

(1) there exists a non-incremental V^i :: [Hijp, PP e4 LHiJp/H 

( 2 ) [Hijp, C [Hajp, 

(3) Pi = Pi U dom(W) 

(4) Hi is from-scratch consistent (DeHnition \B. 1 0[ ). 

Proof. By induction on Vi :: Hi e Jj- Hi;t. 

• Case Eval-term: By Definition |B.2| W — e, so let Pi = Pi. 

(1) Apply Eval-term. 

(2) We have Hi = Hi and Pi = Pi so [Hi J p, = [HiJ p^. 

(3) It follows from dom(W) = 0 and Pi = Pi that Pi = Pi U dom(W). 

(4) It is given (iii) that Hi is from-scratch consistent. 

We have Hi = Hi, so Hi is from-scratch consistent. 

• Case Eval-fork; Similar to the Eval-term case. 


Case 


Hi(q] =v 


( 1 ) 

( 2 ) 

( 3 ) .^ 

(4) 


Hi PJL get (ref q) 4 Hi, (p,obsv,clean, q);retv 

Hi = (Hi, (p,obsv,clean, q)) 
e = get (ref q) 

Hi(q] =v 
R = q;v 
dom(R) C Pi 
{q}c Pi 

[Hijp, (q) = V 
[Hijp, hlL el- [Hijp,;retv 
Let Pi be Pi. 

[HiJp, = [HiJp, 

[HiJp, h]| el- [Hijp,;retv 


W= £ 

[HiJp, C [HiJp, 

Pi = Pi U dom(£) 

Hi from-scratch consistent 
Hi from-scratch consistent 


Eval-getClean 


Given 

n 

Premise 
By Definition 
Given (iii) 

R = q:v 
By Definition 
By rule Eval-getPlain 


B.2 


B.l 


By def. of restriction 
By above equality 


B.2 


By Definition 
If = then C 
Pi =Pi 
Given (iii) 

Hi differs from Hi only in its edges 


• Tasp q = R@ee Hi{qi->eo} = Gi dirty-paths-in(Gi, q] = G 3 

- Eval-thunkDirty 

Hi thunk(nmk, eo) |- G 3 , (p, alloc eo, clean, q);ret (thk q) 











Ha = (G 3 , (p, alloc eo, clean, q)) 
e = thunk(nmk, Co] 
q = k@cu 
R= £ 

W = q:eo 
dom(W) _L Pi 

Pi 

q ^ dom([HiJp,) 


B.2 


Given 

Given 

Given 

By Definition 

n 

Given 


From Definition 


B.l 


[Hijp, thunk(nmk, Co) I- [Hijpilq'— >eo};ret(thk q) By rule Eval-thunkPlain 
( 3 ) Let Pa be Pi U {q}. 

[Hijpilqi—>eo}= [Hi{qi—>eo}Jp| q ^ Pi 

= [dirty-paths-in(Hi{qi~^eo}, q)Jp, q ^ Pi 

= [dirty-paths-in(Hi{qi—>eo}, q), (p, alloc eo, clean, qjjp. From Definition 
[Hijp, thunk(nmk, eo) 4 [Hajpi{qi— >eo};ret (thk q) By above equalities 


B.l 


(1) IS- 

( 2 ) 

(4) 

Case 


[HiJp, C [Hi{qi—>eo}J P2 
[HiJp, c [Gajp2 
[HiJp, C [G3JP2 

[HiJp, C LHaJP2 
Hi from-scratch consistent 
Ha from-scratch consistent 


B.l 


Immediate 
By Definition 
Restriction ignores edges 
Restriction ignores edges 
Given (iii) 

By Lemma 


B.12 


(Consistent graph extension 1 


q = k@cu exp(Hi,q) = eo 


Hi LJL thunk) nmk, eo) 4 Hi , (p, alloc eo, clean, q);ret (thk q) 


Eval-thunkClean 


B.2 


B.l 


Ha = (Hi , (p, alloc eo, clean, q)) Given 
e = thunk) nm k, eo) Given 

q = k@cu Given 

W = q:eo By Definition 

dom)W) _L Pi Given 

q^ Pi 

q ^ dom)[HiJp,) From Definition 

[HiJp, hjl), thunk) nmk, eo) 41- [Hi J p, {qi—>eo};ret )thk q) By rule Eval-thunkPlain 
[Hi Jp, {qi—>eo} = [Hi, )p, alloc eo, clean, q)J p, From Definition B.l and exp)Hi, q) = e 
•a- (1) [HiJp, hlL thunk)nmk, eo) 4 [Hajpiiqi—>eo};ret )thk q) By above equalities 
Since H 2 = Hi, )p, alloc eo, clean, q), parts (2)-(4) are straightforward. 

Case Eva I-ref Dirty: Similar to the Eval-thunkDirty case. 

Case Eval-refClean: Similar to the Eval-thunkClean case. 


Case 


Hi h[[, ei 4) H';retv H' [v/x]ea 44 Ha;t 
Hi pP letxi— ei inea 44 Ha;t 


Eval-bind 


Di ::Hi pP ei 44 H';retv 
(i) I?i satisfactory 
R= )Ri U )Ra-Wi)) 

W = Wi * Wa 


S ubderi vation _ 

By Definition B.7 
By Definition B.2 

ff 


dom)Ri U )Ra -Wi)) C Pi 
dom)Wi * Wa) -L Pi 

I?i reads Ri writes Wi 
Da reads R 2 writes W 2 


Given 

Given 

n 

ff 


















dom(Ri U (R2 - Wi]] C Pi 
dom(Wi * W2) -L Pi 
By i.h. 


(ii) dom(Ri) C Pi 
(ii) dom(W 2 ) -L Pi 

[Hijp, hlL ei 4 [H'Jp/;retv 
[Hijp, C LH'Jp, 

P' = Pi U dom(Wi] 

H' from-scratch consistent 


I?2 "H' hSj [v/x]e2 4 J- H2;t Subderivation 

(i) I?2 satisfactory By Definition 

dom(Ri U (R2 ~Wi])^ Pi Given 

dom(R 2 — Wi) C Pi 

dom(R2) ^ Pi U dom(Wi) 

(ii) dom(R 2 ) C P' 

dom(Wi * W2) -L Pi Given 

dom(Wi) _L dom(W2) From def. of * 

dom{W2) _L Pi U dom(Wi) 
dom(W2) -L P' P' = Pi u dom(Wi) 


B .7 


P' = Pi U dom(Wi) 


(ii) 


( 4 ) IS- 

( 2 ) 

( 3 ).^ 


( 1 ) iS- 


[H'Jp/ hS; [v/xlezii. [H2jp2;t 

LH'Jp.c [H2jp, 

P2 = P' U dom(W2) 

H2 from-scratch consistent 
[Hijp, C [H 2 jp, 

P2 = Pi U dom(Wi) U dom(W2] 

P2 = Pi U dom(W) 

[Hijp, ei 4 [H'Jp/;retv 
[H'Jp- hJL [v/x]e 2 4 LH 2 jp 2 ;t 


By i.h. 


By transitivity of C 
By P' = Pi U dom(Wi; 
By W = Wi * W2 

Above 

Above 


[Hijp, hJJ, letx <—ei in 62 4 J-[H2J P2; t By rule Eval-bind 


Case Eval-app: Similar to the Eval-bind case. 

Case Eval-nest; Similar to the Eval-bind case. 

Case Eval-fix; The input and output graphs of the subderivation match those of the conclusion, as do the read and write 


sets according to Dehnition B .2 Thus, we can just use the i.h. and apply Eval-hx. 
Case Eval-case: Similar to the Eval-hx case. 

Case Eval-split: Similar to the Eval-case case. 

Case Eval-namespace: Similar to the Eval-hx case. 


Case exp(Hi,q) = e' 

del-edges-out(Hi{qH-)e'}, q) = Gj 


Pi, 


e'4f G2;t' 


G 2 {q'—— G2 

all-clean-out(G2, q] 

G2 FJJ, force (thkpo) 4 H2;t 


Hi hJJ, force (thk po) jf H2; t 


— Eval-computeDep 


Given 

By Dehnition 

n 


B .2 


e = force (thkpo) 

R= (Ri UR2] 

W= W2 

I?i reads Ri writes Wi " 

I?2 reads R2 writes W " 

dom(Wi) C dom(W2) " 

We don’t immediately need to apply the i.h. to I?i, because that computation will be done later in the reference derivation. 
But we do need to apply the i.h. to I?2 " G2 FEj e JJ. H2; t. So we need to show part (iii) of the statement, which says that 
each cached computation in the input graph is consistent with respect to an earlier version of the graph. 






Since we’re adding such a computation e' in G2, which is the input graph of 'D2, we have to show that the computation of 
e' (by ) is consistent, which means applying the i.h. to . 


(iii) dom(Ri ] C 
(iii)dom(Wi ] _L Pi 


dom(R] C Pi 
dom(W) _L Pi 


Hi from-scratch consistent 
G \ from-scratch consistent 

::Gl'^\.espace(q)e'4G2;t' 

(1) LGiJp, ^^„(q,e'4LG2jp(;t' 

(2) [G^Jp, C [Gijp; 

( 3 ) P{ = Pi U dom(Wi) 

(4) G 2 from-scratch consistent 

[Gijp; C [Gijp; 


Given (iii) 

Gi differs from Hi only in its edges 
(note that q points to e' but has no cached result) 
Subderivation 
By i.h. 

n 

n 

n 

If = then C 


G2 from-scratch consistent 


By Lemma B. 12 (Consistent graph extension 1 


Having “stowed away” the consistency of e', we can move on to I?2- 


(i) 

V2 ::Gi hS; e 4 H 2 ;t 

I?2 satisfactory 

Subderivation 

I?2 is a subderivation of Vi 

dom(R) C Pi and dom(W) _L Pi 
(ii) dom(R2) C Pi and dom(W2) -L Pi 

Given 

Using above equalities 

(iii) 

Hi from-scratch consistent 

ft 

( 1 ) 

[GiJp, PP e 4 LH 2 jpHt 

By i.h. 

( 2 ) 

LG2JP1 c [H2JP2 

II 

( 3 ) 

P2 = Pi U dom(W) 

n 

( 4 ) 

H2 from-scratch consistent 

n 

[HiJp, = [HilqK^e'IJp, 

= [del-edges-out{Hi{qi—>e'}, q]J p, 

= LG 5 Jp, 

We need to show [GjJ p, = [G2J p, . That is, evaluating e 

Follows from exp (Hi, q] = e' 

Dehnition B.l ignores edges 

By above equality 

—which will be done inside the reference derivation’s version 


of Vz —doesn’t change anything in Pi. 

Fortunately, we know that dom{W) _L Pi and dom(Wi) C dom(W). Therefore dom(Wi ] _L Pi. 

By Lemma B .5 (Respect for write-seti, G2 agrees with Gi on dom(Gj) — dom(Wi). Since Wi is disjoint from Pi, we 
have that G2 agrees with G j on Pi. 

Therefore [Gjjp, = LG2jp,- 

Now we’ll show that [G2J p, = [G^J Pi ’ that is, [G2J p, = [G2{q'—>(e', t')}J p,. 


■ If q ^ Pi then this follows easily from Dehnition |B.l| 

■ Otherwise, q € Pi. We have exp(Gj, q] = e' and therefore exp(G2, q) = e', so updating G2 with q pointing to e' 
doesn’t change the restriction. 


[Hijp, = [G2JP, Shown above 

( 1 ) [HiJp, hP e 4 LH 2 jp,;t By above equality 

( 2 ) [HiJp, C [H2JP, 


• Case 


Hi(q) = (e,t] all-clean-out(Hi, q) 

Hi force (thk q) jj. Hi, (p, obst, clean, q];t 


Eval-forceClean 










Hi = (Hi, (p,obst,clean, q)) 


Given 


B .9 


(i) 


Hi (q) = (e,t) 

Hi from-scratch consistent over Pi 
I?q satisfactory 
dom(Rq) C Pq 
dom(Wq) _L Pq 

R = (Rq, q:(e,t]] 

W= Wq 

To show t hat jP g is consistent, we use assumption (iii) that Hi is from-scratch consistent. We have q:(e,t) in Hi. By 
Definition 


Premise 
Given (iii) 
Definition 

" (ii) “ 
" (ii) 

By Definition 

n 


B .2 


for Eval-forceClean {V — T>q) 


B. 10 b,Dq :: Gq hJl,; e Gq', t is from-scratch consistent for some Pq C dom{Gq ] up to Hi. 


Now we turn to Definition lB. 9 l 

[Gqjp, eJI [Gqjpq udom(W<,);t 

[Gqjpq C [GqJ Pq U dom [Wq ) 

[Gqjp, Udom(Wq) C [Hijp, 

LHiJ Pi l~ajq 41' [Hljpi Udom(Wq))f 
Let Pi be Pi U dom(Wq). 


By Definition 
By Definition 
By Definition 


B .9 


B .9 


B .9 


( 1 ) 

( 2 ) 

(4) 


By Lemma B .8 (Weakening (non-incremental) i 


(1) iS- 

LHiJp 

LHiJp 

LHiJp 

[HiJp 

(2) IS- 

LHiJp, 

LHiJp, 

(3).^ 

Pi 

(4) is- 



force (thk q ] 4f [Hi J ; t 

force (thk q] 41 [Hi , (p,obst, clean, q]J p^; 
h£, force (thk q ] 4 )- [HiJ p^ ; t 
C LHiJ P2 By a property of Definition 

^ [HiJpj By a property of Definition 


By above equality 
By rule Eval-forcePlain 
By Definition' 


B.l 


By above equality 


Pi = Pi U dom(W) 


W = Wn 


B.l 


B.l 


Hi from-scratch consistent Hi differs from Hi only in its edges 


Case all-clean-out((Gi, Gi), qi) 

consistent-action((Gi, Gi), a, qi) 

Gi, (qi, a, clean, qi), Gi h[[, force (thkpo) 41' Hi;t 
Gi, (qi,a,dirty, qi),Gi force (thkpo] 4( Hi;t 


Eval-scrubEdge 



e = force (thk po) 

Given 


Hi = (Gi,(qi,a,dirty,qi),Gi] 
Let G'be Gi, (qi, a, clean, qi], Gi. 

Given 


[GiJp, hL e4 LHiJp,;t 

By i.h. 


LG[Jp, C [HiJpj 

// 

(3).^ 

Pi = Pi U dom(W) 

// 

(4) 

Hi from-scratch consistent 

// 


[HiJp, = [G'Jp, 

Definition B.l ignores edges 

(1) iS- 

[HiJp, PP e4 LHiJp,;t 

By above equality 

(2) 

[HiJp, C [HiJp, 

By above equality 


□ 



















